[Glass] Help understanding a RcReadSet commit conflict

[Mariano Martinez Peck via Glass]

On Fri, Jun 17, 2016 at 5:50 PM, Dale Henrichs <
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> 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>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>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, Halt do: [ :exc | self abortToNewTransaction; handleException:
>> exc. currentCommitConflicts ifNotNil: [ self commitConflicts:
>> currentCommitConflicts ]. self commitToNewTransaction. 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 ?



> 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
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160620/2b33abe0/attachment-0001.html>