Remy Maucherat wrote: > > > Ok all, > > > > Here's a first cut at a rewritten JDBCDescriptorsStore - it uses the > > connection pool from the underlying datasource object to associate each > > transaction with a connection. For the various things that happen > > outside the transactions (mostly initialisation stuff, I think), it also > > keeps around a global connection object which acts as the previous J2EE > > stores did (and the original JDBCDescriptorsStore). > > > > I'm not committing this yet, because I'm not sure enough about how it > > all works - my testing shows things going ok, but the tests I've run are > > far from comprehensive. It'd be great if those people that understand > > the transaction stuff in depth could take a look at the code. > > > > Things that are missing: I ripped out the table creation/removal code > > early to simplify things a bit. I guess I'll put it back before I > > commit, but I never used it anyway. > > > > There's a fair amount of debugging info there too, some of that'll be > > removed before a commit. > > > > Any comments would be very much appreciated. > > Quickly looking at the code, it looks great. Of course, the state handling > is a bit on the complicated side, so it's tough to tell like that ;-) > It's pretty hard to get it to run and pass some tests (like a simple load > test) without having the transaction manager complain unless the state is > correct (or that it totally fakes correctness, but you're clearly not doing > that here). So I'd say it is more than worth to be committed. > (You should have committed it right away, IMHO; if there are problems, we > can fix them later) > > Outstanding job overall (I don't think I would have done a better job) :) > > I got the intenal Tomcat JNDI context working fairly recently (that's a > feature I added specially for Slide, but now it turns some other Tomcat > components are also using it), so it should also be possible to use this > store in the standalone server. > > Remy >
ok. Thanks. I've committed it now, since you seem to think that's a good idea. I've been using it (on our test servers) using the tomcat JNDI context (in tc4.1-dev), and that seems to work very well (except that, if you misconfigure something, it swallows the error messages silently somewhere, I think). Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
