[Glass] Help understanding a RcReadSet commit conflict

[Dale Henrichs via Glass]

On 06/20/2016 06:28 AM, Mariano Martinez Peck wrote:
>
>
> On Fri, Jun 17, 2016 at 5:50 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     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 ...
>
>
> mmmm I am not sure. Checking the code of #_commitPrintingDiagnostics 
> (which I guess it it correct), expects to have "(conflicts at: 
> #'commitResult') == #'success' "     in case of "  self 
> commitTransaction" answering false. And ....  "self commitTransaction" 
>  answering false isn't it the same as doing #commit and getting the 
> TransactionError ?

Well, this is why I want to have more information about your 
TransactionError ... there _are_ a several different places (in the C 
code) that signal a TransactionError that aren't directly ralted to a 
commit failure ... your comment leads me to believe that the you hit an 
reduced conflict related TransactionError which lead you to then resume 
the error ... without knowing the details of the "ignored" 
TransactionError, I can only guess about what might be going on ... The 
fact that you have seen a commit failure with no conflicts and no 
additional information is odd and I am hoping that an "ignored" 
TransactionError might provide additional information ...

I'm finally in the office today (although I may not last long ... 
unfortunately) and I'll ask around for any other possibilities ...

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