Analyzing commit failure - retrying

In my apps I noticed I get regularly some entries in the object log with "commit failure - retrying". Basically that's ok because it can just happen.
But there a lot of entries I can't quite imagine what could be the cause of a commit failure. As an example we have a legal page

http://www.taskfor.us/impressum

which is a statically created pier page and there is nothing going on except seaside and pier. So I would think it has to do with sessions. But I don't know. Either it is the session thing and I think at the place where it occurrs there should be a RC class instead. Or it is something else which I don't know but I want to know.
So to make the long story short: Is there a way to determine which object/objects caused a commit failure so I can separate the oks from the must-fix-thisses?

Norbert

Hi Norbert,

The objectlog entry of the commit failure event holds on to an object. That object is the dictionary returned by "System transactionConflicts" (see GS prog guide, p 134) and contains the information and the conflicting objects.

From my own experience, I sometimes get Rc-Write-Write conflicts on the session dictionary.
And another one I reported (and still chasing too) here: http://code.google.com/p/glassdb/issues/detail?id=303


On 17 Nov 2011, at 11:17, Norbert Hartl wrote:

Norbert,

If you are not using Seaside 3.0.6.2, then the commit conflicts could be coming from within a WALeastRecentlyUsedExpiryPolicy instance...I made a changed in Seaside-Session.gemstone-dkh.140 to use a WARcLastAccessExpiryPolicy to avoid unnecessary commit conflicts under load that I found while doing SS3 testing.

As Johan, notes start by looking at the conflicting objects and work backwards from there ...

When trying to track down commit-related problems, here's a chunk of logging code that I've used in the past. :

        url := waRequest url asString.
        (url = '/seaside/examples/lw') ifTrue: [
                System _enableTraceNewPomObjs.
                (WAObjectLogEntry warn: 'writeSet: ', url request: nil object: System _writtenObjects) addToLog].
        self doCommitTransaction
                ifFalse: [ | conflicts |
                        conflicts := System transactionConflicts.
                        self doAbortTransaction.
                        self
                                saveLogEntry: (WAObjectLogEntry warn: 'Commit failure - retrying' request: aNativeRequest object: conflicts)  
                                shouldCommit: true.
                        ^nil "retry request"].
        (url = '/seaside/examples/lw') ifTrue: [
                WAPlatform current doAbortTransaction.
                WAPlatform current saveLogEntry: (WAObjectLogEntry warn: ''New POM objs: '', url request: nil object: (System _hiddenSetAsArray: 4)) shouldCommit: true.
                System _disableTraceNewPomObjs].

In this code I was trying to track down new pom objects, but grabbing the writeSet right before the commit (especially one that might fail) can be useful in giving a larger context to the commit failure, but this is an example of adding tracing code to help track down a problem:

  - filter on a specific url
  - the writeSet could be grabbed and added to the object log only if the commit fails ...

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, November 17, 2011 3:23:41 AM
| Subject: Re: [GS/SS Beta] Analyzing commit failure - retrying
|
| Hi Norbert,
|
| The objectlog entry of the commit failure event holds on to an
| object. That object is the dictionary returned by "System
| transactionConflicts" (see GS prog guide, p 134) and contains the
| information and the conflicting objects.
|
| From my own experience, I sometimes get Rc-Write-Write conflicts on
| the session dictionary.
| And another one I reported (and still chasing too) here:
| http://code.google.com/p/glassdb/issues/detail?id=303
|
|
| On 17 Nov 2011, at 11:17, Norbert Hartl wrote:
|
| > In my apps I noticed I get regularly some entries in the object log
| > with "commit failure - retrying". Basically that's ok because it
| > can just happen.
| > But there a lot of entries I can't quite imagine what could be the
| > cause of a commit failure. As an example we have a legal page
| >
| > http://www.taskfor.us/impressum
| >
| > which is a statically created pier page and there is nothing going
| > on except seaside and pier. So I would think it has to do with
| > sessions. But I don't know. Either it is the session thing and I
| > think at the place where it occurrs there should be a RC class
| > instead. Or it is something else which I don't know but I want to
| > know.
| > So to make the long story short: Is there a way to determine which
| > object/objects caused a commit failure so I can separate the oks
| > from the must-fix-thisses?
| >
| > Norbert
| >
|
|