Re: outrigger recovery

solomon wu wrote:
> For those prepared transactions, I assume that the participant will call
> getState() of the manager as indicated in the spec.  Then it decides
> whether to rollforward or rollback depending on the result of getState.
> Do you happen to remember which class does this?

The getState calls on the transaction manager happen in
TxnMonitorTask.tryOnce. TxnMonitorTasks exist to poll the appropriate
transaction manager for a given transaction's state. We create a
TxnMonitorTask for a transaction when the transaction prevents a query
under some other transaction (including the null transaction) from being
satisfied and for each prepared transaction recovered after a crash
(there may be some other circumstance, but those are the two main ones).

Does that help?

> For the committed transaction, the transaction is done.  We do not need to
> recover that transaction.  Is that your assumption, too?

Committed transactions are not recovered, but the recovered state has to
be consent with the effects of committed transactions.

--
John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

no files, just services

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html