Yes, that's what I meant (I should have given a fuller answer the
first time). Any error checking and "rollback" to undo "modify entity
A" in case of failure of "modify Entity B" would have to be coded
manually within the lock/unlock block.
Vince
On Wed, Aug 26, 2009 at 1:09 PM, objectuser wrote
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.
G
I've implemented a set of distributed locks for GAE that I posted a
message about previously (especially note the current limitations of
reliability of shared/read locks):
http://groups.google.com/group/google-appengine-java/browse_thread/thread/6abc2092fc3870be/d495d9d82abbf912?lnk=gst&q=lock
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
Hey, Vince,
That's really cool. Does that address the need of the OP though? I
may just not be understanding it fully ...
Thanks!
On Aug 26, 11:15 am, Vince Bonfanti wrote:
> I've implemented a set of distributed locks for GAE that I posted a
> message about previously (especially note the c
Yeah, you're going to have a hard time. In GAE you have to make
significant compromises between model, efficiency and integrity.
I don't fully have my mind around how to compesate for the integrity
issues. However, someone has developed an algorithm for a datastore-
specific 2PC. The code was
