transactionConflicts, commitResult is readOnly ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

transactionConflicts, commitResult is readOnly ?

GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list


On Wed, Mar 22, 2017 at 7:46 AM, Johan Brichau via Glass <[hidden email]> 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?



Probably you already saw what I will mention but some explanation is in the big comment of the method #transactionConflicts.

I also had some scenarios where I run background jobs on separated gems and when handling commit conflicts I don something like this (note the check with #success).



[  xxx ]  on: TransactionError do: [ :ex |
"If we are using RC collections, we may be getting a TransactionError but the commitResult could have been success. So in that case
we ignore the error."
"Even if we try to store the commitConflicts in the instVar of the persisting backgroundProcess instance, there may be cases where this is not stored (like if the further commit fails too or if the background process instance was cleaned as part of the normal clean up). Therefore, in addition to above, we also write down the OOP of the conflicts into the gem log, using #logCommitConflictsToLogFile:"
self logCommitConflictsToLogFile: System transactionConflicts.
((System transactionConflicts at: #commitResult) = #success)
ifTrue: [ ex resume ]
ifFalse: [ 
"Two things. First, I must somehow store the #transactionConflicts BEFORE the abort of the next error handler,
since #transactionConflicts are cleared after abort or release. Second, ideally I would directly store this in this
background process instance. However, since this instance is persistent, the next abort will revert this instance to the last view in the repository and
so I will loose my dirty added transactionConflicts. Therefore, store the conflicts in a temp variable. And then, AFTER the abort, in the error handler, and
BEFORE the commit, I set the conflicts into the background process instance. 
"
currentCommitConflicts := System transactionConflicts.
ex pass ]
]. 
self crTrace: 'BackgroundProcess ' , self asOop printString , ' committed transaction successful'.
on: Error, Halt




 
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



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
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… 
Johan

On 22 Mar 2017, at 14:33, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Mar 22, 2017 at 7:46 AM, Johan Brichau via Glass <[hidden email]> 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?



Probably you already saw what I will mention but some explanation is in the big comment of the method #transactionConflicts.

I also had some scenarios where I run background jobs on separated gems and when handling commit conflicts I don something like this (note the check with #success).



[  xxx ]  on: TransactionError do: [ :ex |
"If we are using RC collections, we may be getting a TransactionError but the commitResult could have been success. So in that case
we ignore the error."
"Even if we try to store the commitConflicts in the instVar of the persisting backgroundProcess instance, there may be cases where this is not stored (like if the further commit fails too or if the background process instance was cleaned as part of the normal clean up). Therefore, in addition to above, we also write down the OOP of the conflicts into the gem log, using #logCommitConflictsToLogFile:"
self logCommitConflictsToLogFile: System transactionConflicts.
((System transactionConflicts at: #commitResult) = #success)
ifTrue: [ ex resume ]
ifFalse: [ 
"Two things. First, I must somehow store the #transactionConflicts BEFORE the abort of the next error handler,
since #transactionConflicts are cleared after abort or release. Second, ideally I would directly store this in this
background process instance. However, since this instance is persistent, the next abort will revert this instance to the last view in the repository and
so I will loose my dirty added transactionConflicts. Therefore, store the conflicts in a temp variable. And then, AFTER the abort, in the error handler, and
BEFORE the commit, I set the conflicts into the background process instance. 
"
currentCommitConflicts := System transactionConflicts.
ex pass ]
]. 
self crTrace: 'BackgroundProcess ' , self asOop printString , ' committed transaction successful'.
 
on: Error, Halt




 
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



-- 


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list
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 an internal bug on this issue (46759 #readOnly
#commitResult (in System class>>transactionConflicts) not clearly
documented)

Dale


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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
Hi Dale,

Thanks for picking this up.

The problem is, of course, that I am suddenly ending up in a ‘read-only’ state… meaning: any change I make goes lost.
I can only exit that state by aborting… which is not what I want to do unless I am sure no state change was lost.

Johan

> On 22 Mar 2017, at 19:13, Dale Henrichs via Glass <[hidden email]> wrote:
>
> 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 an internal bug on this issue (46759 #readOnly #commitResult (in System class>>transactionConflicts) not clearly documented)
>
> Dale
>
>
> 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
>
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list

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


On 03/22/2017 11:13 AM, Dale Henrichs wrote:

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



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list


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
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list
Maybe I should add Parasol does a continueTransaction at the point when its request to webdriver to perform an action in the browser is finished?
That continueTx is needed to see the changes that happened in the seaside gem. 

Parasol commits the state just before doing a http request to webdriver and a continueTx when that request finishes.

Good that I know what readOnly means now. I was indeed understanding it differently.

Johan

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

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


On 03/22/2017 11:13 AM, Dale Henrichs wrote:

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


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


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
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
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


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
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
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" <[hidden email]> 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
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


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



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
In reply to this post by GLASS mailing list

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
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


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


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: transactionConflicts, commitResult is readOnly ?

GLASS mailing list
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 <[hidden email]> 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
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


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



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