> 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


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to