Re: J2EEDescriptorsStore with multiple connections/transactions

[Remy Maucherat <re...@apache.org>]

> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: J2EEDescriptorsStore with multiple connections/transactions

[Remy Maucherat <re...@apache.org>]

> Remy Maucherat wrote:
> >
> 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

Great !

> (except that, if you
> misconfigure something, it swallows the error messages silently
> somewhere, I think).

Yes indeed, in the JNDI resource factory. If you read tomcat-user, you'll
see you're not the only one to have problems here ;-)
The thing is there's really nowhere to report any failure because of the
nature of JNDI (except on the stderr; maybe it would be better to do that
anyway rather than leave users in the dark; or maybe throw a NamingException
with some explanation in more cases - I try to avoid doing that as JNDI
allows interrogating multiple resource factories as long as they return
null).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: J2EEDescriptorsStore with multiple connections/transactions

[Michael Smith <ms...@xn.com.au>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>