[Glass] transactionConflicts, commitResult is readOnly ?

Wed Apr 5 07:10:05 PDT 2017

Hey Dale,

I tried the simple example on both 2.4.4.1 and 3.2.15 no, and I get the same result as you indeed.
My apologies! I should have tested the simple testcase I derived on both platforms… 
I was pretty convinced because now I’m still wondering why I needed to convert the uses of continueTransaction in Parasol to commitTransaction to make it work in 3.2.15.
We did run daily test builds with Parasol on 2.4.4.1 for years now… 

So, it’s back to me then to find the exact difference.. :/

thx
Johan

> On 3 Apr 2017, at 19:54, Dale Henrichs <dale.henrichs at gemtalksystems.com> wrote:
> 
> 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.
> 
>   Exactly what version of 2.4 is being used ?
> 
>   Perhaps the transaction boundaries in 2.4 are not as pictured
> 
> Dale
> 
> On 03/29/2017 10:43 AM, Johan Brichau via Glass wrote:
>> 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 <mailto: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>
>> 
>> 
>> 
>> _______________________________________________
>> 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/20170405/0353a9d9/attachment-0001.html>