[jira] Updated: (RIVER-33) Mahalo implementation doesn't abort transaction after a participant joins with an inconsistent crash count as specifiec

["Mark Brouwer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RIVER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Brouwer updated RIVER-33:
------------------------------

          Component/s: com_sun_jini_mahalo
          Description: 
Excerpt from mailing list message:
{quote}
I'm implementing durable transaction participation as part of Seven and due to my reading of the spec I have a question related to TX.2.3
"Joining a Transaction". It states in the 4th paragraph "When a manager receives a join request, it checks to see if the participant has already
joined the transaction. If it has, and the crash count is the same as the one specified in the original join, the join is accepted but is
otherwise ignored. If the crash count is different, the manager throws {{CrashCountException}} and forces the transaction to abort."

However when I look into the code of Mahalo I can see when rejoining a transaction with a different crash count that {{CrashCountException}} is
thrown, but I can't see where Mahalo forces the transaction to abort, which based on my interpretation of the spec seems to be required. Is my
interpretation wrong or is there a bug in Mahalo (or the code I seem to miss).
{quote}

Seems to be a bug.

  was:
Excerpt from mailing list message:
I'm implementing durable transaction participation as part of Seven and
due to my reading of the spec I have a question related to TX.2.3
"Joining a Transaction". It states in the 4th paragraph "When a manager
receives a join request, it checks to see if the participant has already
joined the transaction. If it has, and the crash count is the same as
the one specified in the original join, the join is accepted but is
otherwise ignored. If the crash count is different, the manager throws
CrashCountException and forces the transaction to abort."

However when I look into the code of Mahalo I can see when rejoining a
transaction with a different crash count that CrashCountException is
thrown, but I can't see where Mahalo forces the transaction to abort,
which based on my interpretation of the spec seems to be required. Is my
interpretation wrong or is there a bug in Mahalo (or the code I seem to
miss). 

          Environment:     (was: N/A)
    Affects Version/s: jtsk_2.1

> Mahalo implementation doesn't abort transaction after a participant joins with an inconsistent crash count as specifiec
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: RIVER-33
>                 URL: https://issues.apache.org/jira/browse/RIVER-33
>             Project: River
>          Issue Type: Bug
>          Components: com_sun_jini_mahalo
>    Affects Versions: jtsk_2.1
>            Reporter: Robert Resendes
>            Priority: Minor
>
> Excerpt from mailing list message:
> {quote}
> I'm implementing durable transaction participation as part of Seven and due to my reading of the spec I have a question related to TX.2.3
> "Joining a Transaction". It states in the 4th paragraph "When a manager receives a join request, it checks to see if the participant has already
> joined the transaction. If it has, and the crash count is the same as the one specified in the original join, the join is accepted but is
> otherwise ignored. If the crash count is different, the manager throws {{CrashCountException}} and forces the transaction to abort."
> However when I look into the code of Mahalo I can see when rejoining a transaction with a different crash count that {{CrashCountException}} is
> thrown, but I can't see where Mahalo forces the transaction to abort, which based on my interpretation of the spec seems to be required. Is my
> interpretation wrong or is there a bug in Mahalo (or the code I seem to miss).
> {quote}
> Seems to be a bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.