Sorry about the slow response, I've been sick. Back to work now... > > > > - From the various store methods, I obviously need to be able to get > > the Connection object for that global transaction ID. However, there's > > nothing passed in that I can use directly for this. What's the 'right' > > way to do this? (my current version, which is still a bit of a mess and > > is fairly untested, keys this from the current thread - and I'm not sure > > that's either a good solution or a sufficient one. Ideas/suggestions? > > The transaction is associated with the thread, so in start you can associate > Thread.currentThread() <-> Xid in a hashtable, and retrieve the Xid later in > the write methods.
Ok. That's what I thought, and had done so far - I just wasn't sure if that was always a valid association. So that bit is fine... > > > - Some things still happen outside transactions (or my keying from the > > current thread is broken, in which case I merely don't know what > > connection to use). Should this be permitted at all? Right now, I just > > keep an extra 'global' connection around for this stuff - but that's not > > a nice solution. > > Very few operations should happen outside a transaction. Probably it happens > only during init. > Yes, you should allow it. Obviously, "during init" is the first thing you get to, so before I added this, it was obviously a pretty major problem :-) > > > - Finally, your last paragraph (above) talks about 'always accept > > enlistment in a transaction' - despite doing a fair bit more reading > > about how the transactions work, I'm not sure what exactly you're > > referring to here. Would you mind going into a little more depth? > > The current stores in Slide only allow to be enlisted in one transaction > (for the rest, they return OUTSIDE). > You could write a store which allows one active transaction at a time (I > think AbstractService does that), or you can allow to be enlisted in all > cases (an let the connection pool do the isolation). Since the database can > do finer grained isolation, you should do option 2 and implement the > start/end/etc methods (you can extend AbstractXAService to do that). ok. Thanks, that's much clearer now. I'll let people know once I have something working... Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
