[Glass] transactionConflicts, commitResult is readOnly ?

[Dale Henrichs via 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.

   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 1gem 2
> ————————
> 1start txstart tx
> 2write on object x
> 3 commit tx
> 4continue tx
> 5write on object x
> 6commit 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 <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
>>
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170403/2e0407cd/attachment-0001.html>