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

[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

[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

[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

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