transactionConflicts, commitResult is readOnly ?

In case it isn't clear, I will add that the #readOnly status occurs when no persistent objects are dirtied (thus my curiousity about the objects in the WRITE-WRITE conflict set)...

Dale

Good Question.

It turns out that both #readOnly and #success indicate successful commits.

I am in the process of determining how any objects can show up in the Write-Write set in a read only transaction:)

I've also submitted aninternal

On 03/22/2017 03:46 AM, Johan Brichau via Glass wrote:

Hi,

Trying to port our Parasol tests from GS2.4 to GS3.2 I encounter a commit transaction issue after executing tests in 3.2 which I do not have in 2.4

After test execution, the result of `System transactionConflicts` has a value #readOnly for the #commitResult.
I don’t find a lot of help to know what that means. 
Actually, except the write-write entry, I don’t really know how to interpret the other symbols because they are not mentioned in the progguide for 3.2

Can someone shed some light on this so I can dig deeper and understand what’s going on?

thx
Johan

Other values in the dict:
#’WriteWrite_minusRcReadSet’ -> anArray( aWADocumentHandler, aWADocumentHandler, aNPSession)

#RcReadSet -> anArray( aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcKeyValueDictionary( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( aWADocumentHandler), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( aNPSession), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( ), aRcCollisionBucket( aWADocumentHandler), aRcCollisionBucket( ), aRcCollisionBucket( aNPSession), aRcCollisionBucket( ), …)

#Write-Write -> anArray( aWADocumentHandler, aWADocumentHandler, aRcCollisionBucket( ), aRcCollisionBucket( ), aNPSession)
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sorry for the late reply.... Allen took a look at this and noted that he was getting transaction failures when he tried to emulate your transaction sequence:

 The transaction example given for gem1 and gem2 should always produce a failure to commit in gem2.  And I see that behavior using two topaz -l  interactively on a 2.4.8 build.

Dale,

I’m back on this, now that I bumped Parasol for Gemstone [1].

I think I experienced the same problems in the Parasol tests themselves, but I must say that I must have had things mixed up when I reported a ‘readOnly’ commit result together with a write-write conflict, as I was not able to reconstruct it. Probably a case of me getting lost in logging….

However:

I fixed the transaction issues by replacing all calls to #continueTransaction with #commitTransaction [see commits in 1].

Since Parasol runs a testcase that drives a webbrowser to perform actions in a Seaside app served by another gem, we need to commit and update the view before and after every ‘browser action’ such that testcases can run like in Pharo (i.e. see the same app state).

I tried to explain what I’m seeing below. There are 2 gems working on the same object x from time 1 to 6:

gem 1 gem 2

———— ————

1 start tx start tx

2 write on object x

3  commit tx

4 continue tx

5 write on object x

6 commit tx -> fails

I’m a bit surprised I get different results in GS 2.4 and 3.2, where the use of continueTransaction was working (we do run these tests in daily builds in 2.4).

When I replace the ‘continue tx’ with a ‘commit tx’ it works in both.

The solution works fine, but I’m left wondering if I’m not understanding continueTx right. 

I thought continueTx was updating the view and any change I make to any object that was updated at the point of invoking the continueTx would not lead to a commit conflict.

Instead, it seems that I only get an updated view but any change I make is still seen with respect to the beginning of my Tx?

thx

Johan

[1] https://github.com/SeasideSt/Parasol/pull/5

On 22 Mar 2017, at 19:47, Johan Brichau <[hidden email]> wrote:

Ok, I’m trying to see if I can reproduce the issue with the Parasol tests themselves.

That would make an easy testcase to reproduce in SmalltalkCI

On 22 Mar 2017, at 19:40, Dale Henrichs via Glass <[hidden email]> wrote:

On 03/22/2017 08:21 AM, Johan Brichau via Glass wrote:

Mariano,

Thanks for sharing that piece of code.

It seems a bit different in my case.
By tracing I noticed that it happens right after a seemingly succesful commit. I.e. the following statements happen immediately one after the other:

System commitTransaction
—> returns true.
System transactionConflicts
—> marks the readOnly ‘commitResult’

Any subsequent commit will always return true but nothing is ever committed.

Puzzled…

It's puzzling to us as well ... can you provide us with a simple test case ... #readOnly should indicate that there were no persistent objects modified by the session doing the commit, and does not represent a status of the system, in fact a #readOnly commit should be the equivalent of an abort ...

Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass