v4 XG transaction behaviour

[GoogleCodeExporter]

Objectify V4 automatically detects access to multiple entity groups and uses an 
XG transaction.  This is not the default behaviour of the underlying datastore 
where XG transactions must be started explicitly.  That creates a concern 
because XG transactions come with the cost of higher latency. Many developers 
may wish to avoid XG transactions for that reason and would prefer that an 
exception is thrown when there is an attempt to perform XG access inside a non 
XG transaction. This prevents code that inadvertently performs XG access when 
the developer did not intent for that to happen. 

A new feature that supports changing the default behaviour would work.

For example:

// Disable automatic XG support.
ObjectifyService.setAutomaticXG(false);

or...

// Disable XG support for the current context.
ObjectifyService.ofy().setAutomaticXG(false);

Original issue reported on code.google.com by jim.trai...@gmail.com on 28 Feb 2013 at 10:12

[GoogleCodeExporter]

Google has stated publicly that enabling XG transactions does not incur a 
performance penalty when a single EG is involved.

Original comment by lhori...@gmail.com on 28 Feb 2013 at 10:28

• Changed state: WontFix

[GoogleCodeExporter]

I'm hoping to avoid accidentally making an XG call - i.e. it creeping into the 
code when not intended and leading to higher latency.  I'd prefer to be 
explicit about it or have the option.  That's the real concern.

Thanks for the quick reply.

Original comment by jim.trai...@jptrainor.com on 1 Mar 2013 at 1:59

[GoogleCodeExporter]

You can make an enhancement request for "Allow a flag that causes my 
application to break when I perform a multiple-group transaction". But really 
this is a kind of premature optimization - you should use XG transactions as 
much as necessary. Better to have a slow transaction than corrupt data.

Original comment by lhori...@gmail.com on 1 Mar 2013 at 2:05

[GoogleCodeExporter]

Thanks, I made that request.

The application server is already mostly done and designed to make single group 
accesses.  There was no XG when most of the code was developed.  Having done 
that, and just now upgrading to objectify v4, I only want XG to be used where I 
explicitly identify it as okay.

Reading the docs I have other concerns as well about slight behavioural 
differences between XG and SG ("single group").  e.g. this comment:

"Note: The first read of an entity group in an XG transaction may throw a 
ConcurrentModificationException if there is a conflict with other transactions 
accessing that same entity group. This means that even an XG transaction that 
performs only reads can fail with a concurrency exception.

Found on this page: 
https://developers.google.com/appengine/docs/python/datastore/overview

It is not clear that I have to worry about that exception when performing a SG 
access or when accessing a single entity group in an XG transaction.  I don't 
want to open the door to such errors inadvertently or otherwise.

Thanks

Original comment by jim.trai...@gmail.com on 1 Mar 2013 at 10:09

[GoogleCodeExporter]

If you dig through the appengine google group you should be able to find 
comments from googlers saying that single-entity transactions are the same 
whether or not XG transactions are enabled, so you won't see the exception on 
read.

Original comment by lhori...@gmail.com on 1 Mar 2013 at 4:44

[GoogleCodeExporter]

Thanks. I can't honestly say that my concern is displaced based on comments in 
a form when the official docs site the caution. One of the advantage of 
objectify has been that it has a light touch.  Just enough to make the 
underlying object store work well with Java.  Some of that appears lost in v4 
insofar as transactions are concerned.  I like the transact methods, and 
automatic retry - I had similar in my code already and have removed it.  I'm 
having trouble getting comfortable with this limitation however.

Original comment by jim.trai...@gmail.com on 1 Mar 2013 at 5:21