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
>
>