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

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>