Persistent Data Issues

3 views
Skip to first unread message

James

unread,
Nov 3, 2007, 10:58:53 PM11/3/07
to OpenSocial Developers
First up, after working with the API for a few hours, I really do like
the implementation. It's very easy and logical to use.

My main questions are about Persistent Data;
1) I can't find any talk of limits to this space anywhere - can we get
some kind of guidelines on what to expect here. It obviously isn't
going to be unlimited and while it's presumably up to the containers,
there must have been some discussion about this. We need to have some
idea about this in order to even begin planning applications that can
be built using this data.
2) Has anyone thought about concurrency? Is there some way we can get
some atomic functions here? If I read some persistent data (say a
counter) then perform some action (say increment it) and then write
back the updated value, we have a fairly obvious race condition if
someone else loads the page and is modifying the same data. (Here's an
example counter implementation that I wrote that will exhibit this;
http://thatsmymouse.com/counter.xml ). In the current implementation
there's no way to hold any kind of lock, or perform any atomic
function on the data. This makes persistent data essentially useless -
even if the data can only be modified by the same user, we end up with
a race condition if the user loads two pages at once. I think this
needs to be addressed pretty quickly!

Thanks and keep up the good work!

Jay Hoover (Snapvine)

unread,
Nov 4, 2007, 3:16:11 PM11/4/07
to OpenSocial Developers
The issue about concurrency seems pretty big. It would be nice to hear
what sort of guarantees you have when dealing with concurrent writes.
Since you are able to write many properties out in a single request,
it seems like you could design your application around any concurrency
issues as long as you can be guaranteed that all property updates in a
single request are atomic. Right now I'm making that assumption in one
of the apps I'm building. Holding a lock on properties (or a set of
properties) would be nice, but probably not necessary most of the
time.

-jay

On Nov 3, 6:58 pm, James <z...@zemaj.com> wrote:
> First up, after working with the API for a few hours, I really do like
> the implementation. It's very easy and logical to use.
>
> My main questions are about Persistent Data;
> 1) I can't find any talk of limits to this space anywhere - can we get
> some kind of guidelines on what to expect here. It obviously isn't
> going to be unlimited and while it's presumably up to the containers,
> there must have been some discussion about this. We need to have some
> idea about this in order to even begin planning applications that can
> be built using this data.
> 2) Has anyone thought about concurrency? Is there some way we can get
> some atomic functions here? If I read some persistent data (say a
> counter) then perform some action (say increment it) and then write
> back the updated value, we have a fairly obvious race condition if
> someone else loads the page and is modifying the same data. (Here's an

> example counter implementation that I wrote that will exhibit this;http://thatsmymouse.com/counter.xml). In the current implementation

Reply all
Reply to author
Forward
0 new messages