[Glass] transactionConflicts, commitResult is readOnly ?

[Johan Brichau via Glass]

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 <https://github.com/SeasideSt/Parasol/pull/5>

> On 22 Mar 2017, at 19:47, Johan Brichau <johan at yesplan.be> 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 <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> 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
>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass <http://lists.gemtalksystems.com/mailman/listinfo/glass>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170329/30fd233d/attachment.html>