directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hayes <>
Subject Re: [bdbje] Using a ThreadLocal to find a Transaction
Date Mon, 19 Apr 2004 23:05:07 GMT
On Apr 16, 2004, at 12:03 PM, Charles Lamb wrote:
> If you use the Collections API, there is already the notion of a 
> current transaction.

You could say there are two parts to the problem of providing a 
"current implicit transaction" that works with the JE API ("base API") 

1- A ThreadLocal-based object is needed for storing the current 
transaction for the current thread.

2- An adapter API, or perhaps in the future the JE API itself, is 
needed that uses the current transaction rather than an explicit 
transaction parameter.

Part 2 is not provided in the current JE product.

However, part 1 is provided by the CurrentTransaction class in the 
com.sleepycat.collection package.  This class has beginTransaction, 
commitTransaction, and abortTransaction methods for managing the 
implicit transaction.  Its getTransaction method could be used by an 
adapter layer for getting the implicit transaction and passing it on to 
the base JE API.

The TransactionRunner class, also in the collections package, provides 
a higher level abstraction for running transactions, performing 
retries, and handling deadlocks.  TransactionRunner uses 

Both CurrentTransaction and TransactionRunner, while designed to be 
used with collections, are not dependent on collections and can be used 
with the base JE API.

Another thing to note is that CurrentTransaction is not a singleton but 
rather is scoped to a JE Environment object.  That way, more than one 
JE Environment can be open at the same time and each will have a 
different "current transaction" per thread.  The 
CurrentTransaction.getInstance(Environment) static method returns the 
instance for a given environment.

Also note is that a complete solution to this problem would provide a 
way to perform database reads without using the implicit transaction, 
in cases where obtaining a read lock is not desired.  In other words, 
just because there is an active transaction for the current thread 
doesn't necessarily mean that you want to use that transaction for 
reading.  For performance reasons you may not want to retain read locks 
for the duration of the entire transaction.

So, in the adapter layer you're discussing, you may want to provide a 
way to read without using the implicit transaction.  If Sleepycat were 
to support the implicit current transaction in the base JE API, I think 
we would want to provide a way to read outside of a transaction.

Passing LockMode.DIRTY_READ is a workaround for this problem, but is 
not a complete solution since you may want to read outside of a 
transaction but only read committed data.


View raw message