Mercurial > hg > blitz_stable
view src/org/dancres/blitz/txn/AbortCommand.java @ 23:b7e52953b7a6
Add some cache/memory statistics to help spot potential exhaustion and other tuning issues.
author | Dan Creswell <dan.creswell@gmail.com> |
---|---|
date | Fri, 28 Aug 2009 17:23:33 +0100 |
parents | 3dc0c5604566 |
children |
line wrap: on
line source
package org.dancres.blitz.txn; import java.io.Serializable; import java.util.logging.Level; import net.jini.core.transaction.UnknownTransactionException; import org.prevayler.Command; import org.prevayler.PrevalentSystem; /** Command to issue abort against transaction held in TxnManagerState */ class AbortCommand implements Command { static final long serialVersionUID = 182858469530698187L; private TxnId theId; AbortCommand(TxnId anId) { theId = anId; } public Serializable execute(PrevalentSystem aSystem) throws Exception { TxnManagerState mySystem = (TxnManagerState) aSystem; try { mySystem.abort(theId); } catch (UnknownTransactionException aUTE) { /* We may have logged the abort command whilst the transaction was in active state which means there's no prior prepare command in the log. If we then run recovery, the first time we'll do anything with the transaction is when we load and execute abort. Because there's no prior prepare, we will have no state loaded for the transaction. Thus, if we can't find the transaction it's okay but we shouldn't take further action. Of course, we could be asked to abort something we're unaware of which can happen under various circumstances (including a buggy TxnMgr) but it's okay to swallow that silently. */ TxnManager.theLogger.log(Level.FINE, "Abort failed - transaction is missing", aUTE); } return null; } public String toString() { return " AB : " + theId; } }