You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Jim Waldo (JIRA)" <ji...@apache.org> on 2007/07/26 16:59:03 UTC

[jira] Created: (RIVER-57) want to register for events with a transaction manager

want to register for events with a transaction manager
------------------------------------------------------

                 Key: RIVER-57
                 URL: https://issues.apache.org/jira/browse/RIVER-57
             Project: River
          Issue Type: New Feature
          Components: com_sun_jini_mahalo
    Affects Versions: jtsk_2.1
            Reporter: Jim Waldo


It would be very nice if the Transaction Manager could generate RemoteEvents
when transactions abort or commit. This way, an object that is not taking place
in a transaction could be notified when a transaction completes either way and
take appropriate action.

The particular reason I want this is that I am designing a system to run jobs
in a distributed environment. I have a server that puts jobs into a queue (a
javaspace). Hosts that can run the job are notified when this happens, bid on
the job, and the winner takes it. The jobs take an undetermined amount of time
and MUST complete. My solution to this part is to make the take the first part
of the transaction and when the job completes, put another object in the space
that is the end of the transaction. The host will renew the lease on the
transaction until the job is done. If the host or the network goes down, the
lease will expire and the transaction will abort and the job will be back in
the space. The job server needs to know when this happens so it can take
appropriate action. It can't just listen for jobs being put in the queue since
they are continually being put there anyway and doing some type of checking
would have too much over head.

Like I said, the ideal solution would be if the job server could register with
the Transaction Manager and get notified when the transaction aborted. Then it
would be a simple matter to fish the job out of the space and take corrective
action.

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


[jira] Updated: (RIVER-57) want to register for events with a transaction manager

Posted by "Jim Waldo (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/RIVER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Waldo updated RIVER-57:
---------------------------

    Priority: Minor  (was: Major)

Originally entered as major (which reflects the effort that would be required to implement) rather than minor (which reflects the importance).

> want to register for events with a transaction manager
> ------------------------------------------------------
>
>                 Key: RIVER-57
>                 URL: https://issues.apache.org/jira/browse/RIVER-57
>             Project: River
>          Issue Type: New Feature
>          Components: com_sun_jini_mahalo
>    Affects Versions: jtsk_2.1
>            Reporter: Jim Waldo
>            Priority: Minor
>
> It would be very nice if the Transaction Manager could generate RemoteEvents
> when transactions abort or commit. This way, an object that is not taking place
> in a transaction could be notified when a transaction completes either way and
> take appropriate action.
> The particular reason I want this is that I am designing a system to run jobs
> in a distributed environment. I have a server that puts jobs into a queue (a
> javaspace). Hosts that can run the job are notified when this happens, bid on
> the job, and the winner takes it. The jobs take an undetermined amount of time
> and MUST complete. My solution to this part is to make the take the first part
> of the transaction and when the job completes, put another object in the space
> that is the end of the transaction. The host will renew the lease on the
> transaction until the job is done. If the host or the network goes down, the
> lease will expire and the transaction will abort and the job will be back in
> the space. The job server needs to know when this happens so it can take
> appropriate action. It can't just listen for jobs being put in the queue since
> they are continually being put there anyway and doing some type of checking
> would have too much over head.
> Like I said, the ideal solution would be if the job server could register with
> the Transaction Manager and get notified when the transaction aborted. Then it
> would be a simple matter to fish the job out of the space and take corrective
> action.

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