I see what you're saying ... you're addressing the integrity issues
around concurrent modifications. As is, "what if someone makes an
inconsistent modification to A while I'm trying to update B" ...
I was thinking of it in terms of, what if "modify entity A" works and
"modify entity B" fails.
Good stuff!
On Aug 26, 11:51 am, Vince Bonfanti <vbonfa...@gmail.com> wrote:
> I thought it did, but I may not have fully understood the question.
> Using distributed locks would allow him to implement atomicity
> (synchronization) of transactions in his application code without
> modifying his data model, something like this:
>
> exclusiveLock.lock();
> try {
> // modify entity A
> // modify entity B
> } finally {
> exclusiveLock.unlock();
> }
>
> Assuming that entities "A" and "B" are in different entity groups, and
> therefore he can't use the built-in transaction support provided by
> the datastore.
>
> Vince
>
> On Wed, Aug 26, 2009 at 12:44 PM, objectuser<kevin.k.le...@gmail.com> wrote:
>
> > Hey, Vince,
>
> > That's really cool. Does that address the need of the OP though? I
> > may just not be understanding it fully ...
>
> > Thanks!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~----------~----~----~----~------~----~------~--~---
