Remy Maucherat wrote: > > > > That's fine for now. Actually, the usage the store makes of the pool is > not > > > correct at the moment, so a partial rewrite will be indeed needed. > > > > Ok. I'll leave it as-is, then. If you have time to give me some hints as > > to how the J2EE stores _should_ be using the connection pool, then > > that'd be appreciated. I don't mind doing the work of actually rewriting > > it, but I'm not sure (I haven't done much database stuff) where it is > > appropriate to get a new connection, etc. > > I think you need to associate 1 connection <-> 1 global transaction ID, and > put back the connection in the pool at the end. That's also what Dirk > suggested, if I remember well. > IMO, you also can also fully rely on the DataSource TX isolation (or at > least allow it as an option), and always accept enlistment in a transaction > (the DB will then handle the rest, which could be finer grained, so it > should end up being faster).
Thanks for this - I've started implementing it, but (unsurprisingly) come up against a couple of little things: - 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? - 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. - 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? Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
