[Glass] Help understanding a RcReadSet commit conflict

[Dale Henrichs via Glass]

Okay ... I'm interested in the TransactionError that is not a 
TransactionError ... that is a bit surprising to me and I'd be 
interested in addtional details ... don't think that it's related to the 
current problem, but who knows :)

What does the #commitConflicts: method do?

So far I don't see anything suspicious ...

Is this problem reproducable?

It may be time to record a stack in the log and perhaps take a look at 
System class>>_commitPrintingDiagnostics for logging the commit 
conflicts to the log as well ... The code in System 
class>>_commitPrintingDiagnostics implies that not all fields are in the 
transactionConflicts dictionary are set, so that may be a red herring.

Dale

On 6/17/16 11:56 AM, Mariano Martinez Peck wrote:
>
> On Fri, Jun 17, 2016 at 3:17 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     Mariano,
>
>
>     It has been awhile since I've done any reduced conflict work, so
>     the details of the reduced conflict mechanism need to be paged
>     back in ... with a bit of poking around I believe that the
>     RcReadSet is not involved directly in the actual conflict,
>     especially since the #Write-Write set is empty ... from the
>     information I've seen here, there shouldn't have been a conflict ...
>
>
> That was the part I didn't understand. As the rest of the keys were 
> empty and the result was #failure , I couldn't understand why 
> RcReadSet (the only none empty key) would make the commit to fail....
>
>     Is there a reason that you are not showing the full set of fields
>     in a conflictDictionary? I would expect to see fields for each of
>     the following (from System class>>transactionConflicts):
>
> No. Actually, I pasted all I can see from that dictionary. So maybe 
> the problem is how I am capturing and persisting this?
> Here [1] you can see how I do my best to capture the transaction 
> conflicts for later analysis. Note that since this is a background 
> process I cannot immediatly debug it. That's why I try to persist the 
> commit conflicts together with my persistent background instance 
> before I loose it
>
>          Key                Conflicts
>      Read-Write          StrongReadSet and WriteSetUnion conflicts.
>      Write-Write         WriteSet and WriteSetUnion conflicts.
>      Write-Dependency    WriteSet and DependencyChangeSetUnion conflicts.
>      Write-WriteLock     WriteSet and WriteLockSet conflicts.
>      Write-ReadLock      WriteSet and ReadLockSet conflicts.
>      Rc-Write-Write      Logical write-write conflict on reduced
>     conflict object.
>      WriteWrite_minusRcReadSet  (WriteSet and WriteSetUnion conflicts)
>     - RcReadSet)
>
>     Both the Write-Dependency and Rc-Write-Write fields would have
>     useful information if they weren't empty ...
>
>     Barring additional information I suppose it might be useful to see
>     the error message and any other information from the log file
>     (perhaps a stack?)
>
>
> I suspect I am capturing/persisting wrongly the commit conflicts.
>
>
> Thanks in advance for any help.
>
>
> [1] http://ws.stfx.eu/JRWK7K047PUO
>
>
>     Dale
>
>     On 6/16/16 7:54 AM, Mariano Martinez Peck via Glass wrote:
>>     Hi,
>>
>>     My code that runs background jobs on a separate gem (based on
>>     Otto's code...similar to ServiceVM), stores the commit conflict
>>     information inside the persistent background process instance for
>>     post commit conflict analysis.
>>
>>     I have a job that failed today and with the following commit
>>     conflict info:
>>
>>     Inspect aFaBackgroundProcess/aSymbolDictionary(
>>     #'WriteWrite_minusRcReadSet'->anArray( aDictionary( )),
>>     #'commitResult'->#'failure', #'RcReadSet'->anArray(
>>     aRcCollisionBucket( aRcKeyValueDictionary( ,........)
>>     --------------------
>>     .                -> aSymbolDictionary(
>>     #'WriteWrite_minusRcReadSet'->anArray( aDictionary( )),
>>     #'commitResult'->#'failure', #'RcReadSet'->anArray( aRcCollisionB...
>>     ..               -> aFaBackgroundProcess
>>     (class)@         -> SymbolDictionary
>>     (oop)@           -> 15059544321
>>     (committed)@     -> true
>>     (notTranlogged)@ -> nil
>>     1@               -> #'commitResult'->#'failure'
>>     2@               -> #'RcReadSet'->anArray( aRcCollisionBucket(
>>     aRcKeyValueDictionary(
>>     'siteDB-debris-gemstone'->aFaGemStoneDataStore)),
>>     aRcCollisionBucket( aRcK...
>>     3@               -> #'Write-Write'->anArray( aDictionary( ))
>>     4@               -> #'WriteWrite_minusRcReadSet'->anArray(
>>     aDictionary( ))
>>
>>
>>     So... commitResult is #failure and the only thing set up is
>>     RcReadSet. I have searched in the programming guides for
>>     RcReadSet and I found nothing. I am inspecting the array of it,
>>     but it is of size 973...which makes it impossible to understand
>>     what it really caused the conflict.
>>
>>     Is there any tip on how can analyze this better?
>>
>>     Thanks,
>>
>>
>>     -- 
>>     Mariano
>>     http://marianopeck.wordpress.com
>>
>>
>>     _______________________________________________
>>     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 <mailto: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/20160617/5099ec85/attachment-0001.html>