Hi,
Have a look at this to understand the issues:
http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine
regards
didier
On Jul 10, 11:09 pm, mscwd01 wrote:
> Hey
>
> I'm using JDO and need to update two entities both of which reside in
> their own entity group. As I cannot use a
I might add that you could add a try/catch/finally: use a transaction
on the first operation
in the try block that can be rolled back if a succeeded flag is
false in the finally block;
after the 2nd operation in the try block the succeeded gets set to
true; and if you
use the referred patt
The try/catch/finally method seems better than the convoluted method
mentioned in the blog. One question though, what is the "success flag"
you mentioned? I'm confused as to how I can have two transactions in
one try/catch and make sure both succeed. Maybe a quick code sample
would help if you have
Here's an implementation. You might want to add checks for read
staleness, and think about using a task
structure for the operations to make retry easier.
The unit test structure is from from
http://code.google.com/appengine/docs/java/howto/unittesting.html
package com.climbwithyourfeet.events.
That's awesome, many thanks for taking the time to explain that.
On Jul 12, 9:37 am, Nichole wrote:
> Here's an implementation. You might want to add checks for read
> staleness, and think about using a task
> structure for the operations to make retry easier.
>
> The unit test structure is from
One final question. In the afterCompletion method when the userAccount
has the amount subtracted, would you call pm.makePersistent() on the
userAccount object? If you don't it wouldn't persist the change made
to the userAccount surely? If this is the case would you just look to
see that the object
Yes, you'll need to add structure to the entity update method or
surrounding it to persist the state of the entity (and use real
entities!
The test structure is purely to provide runnable code to demonstrate
one way to approach the problem).
For the 2nd update, if you recently fetched or refresh
Okay, so after testing this, I have one issue.
If the second update fails (in the afterCompletion method) there is no
way to rollback the transaction to prevent the first update (adding 10
to userGameCredits object) taking effect - as the transaction is no
longer active at this point.
Am I missing
Good point, I rewrote the code below to better use the available
connections
and improve the pattern.
Regarding update 1 being committed and update 2 failing, the
first is already committed, yes. I think one has to use a retry for
the
2nd update (using the task queue structure) for the 2nd ope
Thanks for the update. It's a pity you cant check to see if the first
transaction committed before it leaves an "active" state, that'd make
things so much easier. I really needed the two updates to occur as
quickly as possible so relying on the second update to continue
retying via the task queue,
Last question, promise!
I decided to do what the above exception so kindly suggested and
created a new PersistenceManager as follows:
PersistenceManagerFactory pmfInstance =
JDOHelper.getPersistenceManagerFactory("transactions-optional");
pmfInstance.setNontransactionalRead(true);
pmfInstan
The 2 properties that you are trying to set nontransactionalRead and
nontransactionalRead are what is set in the jdoconfig.xml.
They define whether that persistence manager will allow queries
that are not in a transaction. The datanucleus documentation isn't
as readily available for jdo 2.3, so h
The answer to the nontransactionalread and write are below, but
meanwhile, if you really do need those updates to be as close
to atomic as possible, then you need them in the same entity
group so they're co-located in the distributed file system.
On Jul 18, 2:02 am, mscwd01 wrote:
> Thanks for th
By the way, if you wanted vary your jdoconfig.xml settings
knowing which are impl in appengine, here's a link to
appengine datanucleus test code:
http://code.google.com/p/datanucleus-appengine/source/browse/trunk/tests/META-INF/jdoconfig.xml?r=514&spec=svn514
On Jul 18, 8:44 pm, Nichole wrote:
Also, if you wanted to use that same pattern of 2 transactions for
a delete, you should use a query for the delete to avoid conflict
with the cache.
tx.begin();
qRT = pm.newQuery(Event.class);
qRT.setFilter(" (key == k) ");
qRT.declareParameters("com.google.appengine.api.datastore
15 matches
Mail list logo
