In most cases it is fairly obvious from the modified objects (how many places in your code touch that object?), but the definitive proof would come in the transaction logs. See Chapter F, “Object State Change Tracking,” in the System Administration Guide.
James
> On Dec 29, 2014, at 12:24 AM, Pieter Nagel via GemStone-Smalltalk <
[hidden email]> wrote:
>
> I'm trying to debug sporadic write-write commit failures. There are many
> methods, like System>>transactionConflicts or
> System>>_commitPrintingDiagnostics that can give me the OOPs of the
> objects that could not be committed.
>
> But is there any mechanism for finding out which other session(s) are
> responsible for the commit failure?
>
> In other words, if I want to debug WHO caused the conflict, not what was
> involved in the conflict.
>
> _______________________________________________
> GemStone-Smalltalk mailing list
>
[hidden email]
>
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Locked
