[Glass] transactionConflicts, commitResult is readOnly ?

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Wed Mar 22 06:33:10 PDT 2017


On Wed, Mar 22, 2017 at 7:46 AM, Johan Brichau via Glass <
glass at lists.gemtalksystems.com> 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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170322/a4656973/attachment-0001.html>


More information about the Glass mailing list