You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Remy Maucherat <re...@apache.org> on 2002/02/07 03:33:33 UTC

Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

> Remy Maucherat wrote:
> >
> > >   Add the database test statements and calls to
> > > connectIfNeededAndPossible()
> > >   to the J2EEContentStore as well - now the store will reconnect to
the
> > >   database if the connection stops working (if, for example, the
socket
> > >  times out or is otherwise invalidated).
> >
> > I don't think that's a good idea. I would think the connection handling
is
> > the responsability of the connection pool.
>
> I would think so too, but because of the way the J2EE stores are
> structured, this was the appropriate way to make it work - it'd probably
> be worth rewriting the stores more extensively at some point, but I
> don't really know the J2EE stuff well enough to do this at the moment.
> (the patch you were responding about is basically the same as one I
> committed to the J2EEDescriptorsStore - I forgot about the content store
> since I don't use it).
>
> If you want to revert my patch, I don't mind - but _something_ is needed
> to make this work right.

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.

BTW, sorry for the lack of responsiveness these days. I've been travelling
lately (and I don't handle jet lag very well :-(), and spending lots of time
on Tomcat.

Remy


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


Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

Posted by Michael Smith <ms...@xn.com.au>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

Posted by Remy Maucherat <re...@apache.org>.
> Remy Maucherat wrote:
> >
> > 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?

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.

>  - 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.

>  - 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).

Remy


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


Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

Posted by Michael Smith <ms...@xn.com.au>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

Posted by Remy Maucherat <re...@apache.org>.
> > 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).

Remy


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


Re: cvs commit: jakarta-slide/src/stores/slidestore/j2ee/J2EEContentStore.java

Posted by Michael Smith <ms...@xn.com.au>.
> 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.

> 
> BTW, sorry for the lack of responsiveness these days. I've been travelling
> lately (and I don't handle jet lag very well :-(), and spending lots of time
> on Tomcat.

Not a problem - my responsiveness was... well, zero, for most of
december and january (I was travelling too - with almost no useful
computer access most of the time) :-)

Michael

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