[Glass] transactionConflicts, commitResult is readOnly ?

[Paul Baumann via Glass]

You are correct in your understanding of how continueTransaction should
work. You say that the same code had worked in another release, so expect a
release bug or release change.

There had been a period when an engineer thought continueTransaction could
be deprecated and functionality had to be restored later once customers
(like me) said how important it is to have that behavior. I recall that how
a failed continueTransaction is reported remained a difference between
releases. Release notes would explain the behavior difference.

Note that it is important to check the result of a continueTransaction and
abort changes when conflicts exist. Your example should not have conflicts
though if always in that sequence and gem 2 had not dirtied that object
before the continueTransaction.

Paul Baumann



On Mar 29, 2017 1:43 PM, "Johan Brichau via Glass" <
glass at lists.gemtalksystems.com> 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

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> 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
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/20170329/77c4b6df/attachment.html>