[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transaction id within a trigger
- To: mckoidb@xxxxxxxxx
- Subject: Re: Transaction id within a trigger
- From: Tobias Downer <toby@xxxxxxxxx>
- Date: Tue, 22 Feb 2005 16:07:34 -0800
- Delivered-To: mailing list mckoidb@mckoi.com
- Mailing-List: contact mckoidb-help@mckoi.com; run by ezmlm
- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
This looks good. There is already a private identifier in every
transaction, but it is more of a 'version identifier' in that it is used
to represent a specific version of the database. Two transactions may
share the same version identifier if they happen to share the same
version. In your implementation, it looks like you want an entirely
unique identifier for each transaction which I think is a useful
addition. I don't think you need to call 'getNextTransactionId()' from
commit/rollback because these methods should only be called once, unless
I misunderstand and a new transaction id is useful after a
commit/rollback. Also, static synchronized methods should be kept to an
absolute minimum because they can become a JVM wide bottleneck. Perhaps
these static functions should be moved into com.mckoi.database.Database?
Toby.
R.W. Shore wrote:
> For some testing I’m doing, I need to be able to extract a reasonably
> unique transaction id from within a trigger, an id that changes after a
> commit (or rollback). I’m sending a .zip file containing the modified
> source classes to your private address, only to prevent the file from
> being reflected to everybody on the list. The base for the changes is a
> CVS sync done yesterday. The changes themselves are fairly simple and
> are marked with an RWS comment in the source:
>
>
> o Add a long transactionId attribute to DatabaseConnection
>
> o Increment the transaction id in the commit() and rollback() methods
>
> o Modify the inner class in DatabaseConnection used by
> ProcedureConnection with a getTransactionId() method that references its
> enclosing DatabaseConnection
>
> o Modify ProcedureConnection with a getTransactionId() method that a
> trigger can use
>
> I’ve tested this enough to be confident that there are no unfortunate
> side-effects, so I’m offering the mods to you.
>