Re: How can I reduce locking at storage level

Jason Madden <[email protected]>
Newsgroups gmane.comp.web.zope.zodb
Message-ID <-8239672014120164442@unknownmsgid>
Oh, I probably should have mentioned: one can examine the Connections
joined to a transaction to determine if they have added or mutated any
objects, and decide to commit or abort based on that. But we found
that to not only be an invasion of the internal workings of the
transaction/Connection, but quite fragile (it's easy to modify objects
without realizing it). So we found looking at the higher semantic
level to be better, for us.

On Mar 3, 2016, at 02:44, Jason Madden <[email protected]> wrote:

>> On Mar 3, 2016, at 01:19, Sanjay Rao <[email protected]> wrote:
>> How can I make sure that locking is not done for such read-only transactions ?
>
> I think the basic idea is to abort instead of commit such a transaction.
>
> How and when to do that, is I suppose it's probably application
> specific. For our own case of a WSGI (http) app, we wrote a custom
> transaction middleware (to replace the usual transaction middleware)
> that *always* aborts the transaction on requests that semantically
> aren't supposed to have side-effects, such as the common GET request.
>
> Not only did this eliminate a *lot* of locking for commits that
> /shouldn't/ change anything (at least under RelStorage), it helps
> enforce programmer discipline. There's been some private talk about
> this before, with the implication that it was at least a decent idea.
>
> It's really not complicated to write, although it does have to
> incorporate the retry logic usually found in other WSGI transaction
> managers, or at least our implementation did, IIRC--it's been awhile
> since I've checked. I can try to see about posting it somewhere if
> there's interest, though I suspect there's (again) some app-specific
> logic there so it may not be that helpful.
>
> Jason

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.