[Glass] Help understanding a RcReadSet commit conflict

[Mariano Martinez Peck via Glass]

On Fri, Jun 17, 2016 at 3:17 PM, Dale Henrichs via Glass <
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 listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> 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/20160617/8025e77f/attachment.html>