Hi Sam,
Is there any way you could slightly refactor the query so that it
can be run in a transaction? Transactions can only operate on one
entity group at a time; so, perhaps you can set the a partner as the
parent of CCode.
So your query (in Python) could look more like:
def txn():
partner_key = db.Key.from_path('Partner', intPartnerID)
ccode = CCode.all().filter('Assinged', 0)\
.filter('ExpireDate >=', dtCompareDate)\
.ancestor(partner_key).get()
if not ccode:
# handle no ccode....
ccode.SessionID = strSessionID
ccode.Assigned = 1
db.run_in_transaction(txn)
On Wed, Jul 14, 2010 at 11:17 AM, Sam <[email protected]> wrote:
> In working with the data store, I've been able to solve all of my
> "issues" (coming from a RDBMS background, had to rethink a few
> things!), save for one. In the application I'm working on, it's
> necessary to "reserve" a record at a moment in time and then display
> that record to the end user, ensuring that each user gets a single
> record and no duplicates are issued. Working with the record prior,
> and using SQL as an engine, I was able to use the following query:
>
> UPDATE CCode SET SessionID = '" + strSessionID + "', Assigned = 1
> WHERE Assigned = 0 AND PartnerID = " + str(intPartnerID) + " AND
> ExpireDate >= '" + str(dtCompareDate) + "' Limit 1"
>
> This would update the record in one pass and effectively reserve the
> record for the established session, with no time lost inbetween
> issuing the update and recording the change while SQL handled any
> conflict resolution should two people request a record at the same
> time.
>
> However, dealing with datastore, I seem to be running into some
> problems with timing and wanted to know if anyone had any creative
> ways around it.
>
> I realize that I can run a standard GqlQuery to return the results I
> need and then update based on the returned result and add the session
> to the record without a problem. What concerns me is the timing
> factor. During the time it takes for the query to execute and the
> resulting put() statement, it would be possible for another user to
> arrive and make the same basic query recalling the same record set. I
> know I could check for updates against the datastore before writing
> back (used to do this years ago...), but this could potentially cause
> a deadlock condition when the load on the system became greater and
> multiple simultaneous users needed access to the records for selection
> and updating.
>
> Any thoughts on how to work around this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" 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?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" 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?hl=en.
