This will tell you what type of datastore you are running against, but I don't think it will help you in the development env: http://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/api/datastore/DatastoreService.java#388
On Tue, Oct 18, 2011 at 2:02 PM, Jeff Schnitzer <[email protected]> wrote: > Dunno about production, but the developer mode takes issue with it. > Even a simple single-entity transaction commit fails in M/S mode with > the test harness - ie, without calling this method: > > > LocalDatastoreServiceTestConfig.setDefaultHighRepJobPolicyUnappliedJobPercentage(100) > > commit() always produces this: > > java.lang.IllegalArgumentException: transactions on multiple entity > groups only allowed in High Replication applications > > :-( > > Jeff > > On Tue, Oct 18, 2011 at 1:44 PM, Alfred Fuller > <[email protected]> wrote: > > I believe (you should test this) that it won't do any harm to set XG=true > in > > master slave (it will just ignore you). > > > > On Tue, Oct 18, 2011 at 1:28 PM, Jeff Schnitzer <[email protected]> > wrote: > >> > >> On Tue, Oct 18, 2011 at 9:07 AM, David Gay (Google) <[email protected]> > >> wrote: > >> > > >> > One other consideration: XG transactions do not work on master/slave. > >> > While the default could be different depending on whether HRD is used, > >> > that definitely has drawbacks. > >> > >> How can I detect if running on HRD vs M/S? I don't see anything on > >> SystemProperty. I could try starting an XG transaction and catching > >> the exception, but that would add an extra RPC to every Objectify > >> app's startup time :-( > >> > >> The XG issue seems pretty easily solved by documentation: > >> > >> 1) If you're running on M/S, you can only use one entity group in a txn. > >> 2) If you're running on HRD, you can use up to 5 entity groups in a txn. > >> 2a) If you use multiple entity groups in a txn, this is implemented > >> with 2pc and may produce surprising effects like > >> ConcurrentModificationException on read. This doesn't really matter > >> in practice if you use the RepeatInTransaction pattern. > >> > >> Put it this way: Non-ancestor queries work funky on the HRD too. Yet > >> I don't need to set a special flag just to issue non-ancestor queries. > >> Understanding eventual consistency and exotic transaction behavior is > >> just part of working with GAE. Magic flags that enable otherwise > >> expected behavior don't really help. > >> > >> Jeff > >> > >> -- > >> 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 > >> [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/google-appengine-java?hl=en. > >> > > > > -- > > 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 > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/google-appengine-java?hl=en. > > > > -- > 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 > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
