You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/04/16 17:45:32 UTC

[rms] RE: Using a ThreadLocal to find a Transaction

Ooops I should have categorized this with the [rms] header sorry!

> -----Original Message-----
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> Sent: Friday, April 16, 2004 11:40 AM
> To: bdbje@sleepycat.com
> Cc: 'Apache Directory Developers List'
> Subject: Using a ThreadLocal to find a Transaction
> 
> Hi,
> 
> 
> I was just looking at an API I'm implementing where one implementation
> uses JE as the backing store and I was thinking about how I can avoid
> passing through a Transaction object so JE can make use of it.  The
> API can not include the Transaction as an argument in every method
> that operates against the backing store.  My first inclination was to
> use a ThreadLocal which could be checked for the presence of a
> Transaction.  If one is present then it would be supplied to the
> JE operation if one is not present then null would be used.
> 
> Is this a mechanism that could be used with JE API's to avoid having
> to directly specific the transaction each time as an argument?  I know
> you want the API to remain as close to the original BDB API so those
> used to BDB can rock and roll with nominal learning curves but Java
> does offer some neat constructs that obviates the need to explicitly
> specify the Transaction as a method argument every time.
> 
> It might be nice not to have to worry about providing the Transaction
> which can be checked for by the JE method itself using the ThreadLocal.
> There is nothing stopping me from doing this myself in those classes
> that make the calls to JE but I just thought I'd see if you guys
> thought of it and if so why it's not used.  I'm sure the idea must
> have occurred at some point.
> 
> 
> Thanks,
> Alex
> 
>