Here's an example on using transactions: http://code.google.com/appengine/docs/java/datastore/transactions.html
<http://code.google.com/appengine/docs/java/datastore/transactions.html>If you scroll down, there's an example for a transactional get and save: // PersistenceManager pm = ...; Transaction tx = pm.currentTransaction(); String id = "jj_industrial"; String companyName = "J.J. Industrial"; try { tx.begin(); Key k = KeyFactory.createKey("SalesAccount", id); SalesAccount account; try { account = pm.getObjectById(Employee.class, k); } catch (JDOObjectNotFoundException e) { account = new SalesAccount(); account.setId(id); } account.setCompanyName(companyName); pm.makePersistent(account); tx.commit(); } finally { if (tx.isActive()) { tx.rollback(); } } It looks like you came to this conclusion also, albeit using JPA. On Tue, Jan 26, 2010 at 2:29 PM, Todd Vierling <[email protected]> wrote: > Hi Ikai, thanks for responding... > > On Jan 26, 2:28 pm, "Ikai L (Google)" <[email protected]> wrote: > > I think there's actually a misunderstanding here - we don't guarantee > > uniqueness of a key name. A String key is encoded into a datastore Key. > The > > datastore is, at its lowest layer, a key-value store. Uniqueness is > > guaranteed because if you save an entity using a Key that is already used > in > > the datastore, it will overwrite the value stored at the current Key. > > This is exactly what I was seeing, and trying to use as a basis for a > programmatic uniqueness constraint. > > > It's sometimes easy to conceptualize the datastore as a giant, > distributed > > Hashtable. > > > > That being said, yes, if you must make sure no value exists at the > current > > key location, there most definitely exists a race condition. > > The logic I _desire_ is to have some way to prevent a race condition > at the application level, e.g., when a user is selecting a login > username. Having two users with the same username would be bad; but > also having one user's login information clobber the other's because > of datastore operation timing is bad too. > > In the relational world, this is achieved via a UNIQUE constraint on a > field/column. In the case of a DHT as you compare here, it's usually > by either preventing writes to an existing entity (atomic check-and- > set), or by returning the already-existing value (atomic replace). > > So if the datastore doesn't support any of these notions, what is the > correct/preferred method to prevent an application-level race > condition when writing a value that must have a unique piece of data? > There seems to be no documentation about this concept anywhere. > > -- > 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]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- Ikai Lan Developer Programs Engineer, Google App Engine http://googleappengine.blogspot.com | http://twitter.com/app_engine -- 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.
