[Glass] Help understanding a RcReadSet commit conflict

[Dale Henrichs via Glass]

On 6/17/16 1:40 PM, Mariano Martinez Peck wrote:
>
> On Fri, Jun 17, 2016 at 5:30 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     On 6/17/16 1:26 PM, Mariano Martinez Peck wrote:
>>
>>
>>     On Fri, Jun 17, 2016 at 5:10 PM, Dale Henrichs
>>     <dale.henrichs at gemtalksystems.com
>>     <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>
>>
>>
>>         On 6/17/16 12:56 PM, Mariano Martinez Peck wrote:
>>>         Hi Dale,
>>>
>>>         On Fri, Jun 17, 2016 at 4:20 PM, Dale Henrichs
>>>         <dale.henrichs at gemtalksystems.com
>>>         <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>
>>>             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 :)
>>>
>>>
>>>         Yes, but I don't know how to give more information. More below.
>>         Well, right now you are resuming a TransactionError and I
>>         would want to see the stack and the description of the actual
>>         error ... it might be related to the current problem ... if
>>         you are "ignoring a meaningful" it may have an impact of
>>         future commits.
>>>
>>     As far as I can understand from my own code hahahhaha there is no
>>     "actual error". *I do not #resume the TransactionError but
>>     instead I do a #pass*. Therefore the next error handler:
>>
>>     on:Error, Haltdo:[ :exc | selfabortToNewTransaction;
>>     handleException:exc. currentCommitConflicts ifNotNil:[
>>     selfcommitConflicts:currentCommitConflicts ].
>>     selfcommitToNewTransaction. exc return ]
>     No you are resuming a TransactionError when the commitResult is
>     success and I am very curious about this TransactionError:
>             [
>                 System commit.
>                 ] 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."
>                     ((System transactionConflicts at: #commitResult) =
>     #success)
>                         ifTrue: [ ex resume ]
>
>
> Ahhh yes, if it was #success I do #resume.
> *However, just for the record note that transaction error that caused 
> the final error has #failure as #commitResult. So we are not talking 
> about the same TransactionError. But maybe... the original 
> TransactionError that we #pass may have somehow raised the next 
> #failure TransactionError ? That's what you have in mind?*
> *
> *
> Thanks!
>
Yes ... I can't be sure but I don't think you should be getting a 
TransactionError for a successful commit ... so that means something 
went wrong and _if_ this particular error was immediately preceeded by a 
"resumed TransactionError" then we might have a lot more information and 
perhaps we can get to the bottom of this ... I also don't think that you 
should get a TransactionError claiming that there were commit conflicts 
when there are no commit conflicts present in the transaction conflicts 
dictionary ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160617/a75073cc/attachment.html>