Re: [JBoss-dev] JbossTX vs. Tyrex
David Jencks wrote:
> On 2002.10.03 22:12:42 -0400 Igor Fedorenko wrote:
>
>>David Jencks wrote:
>>
>>>On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
>>>
>>>
David Jencks wrote:
>Hi Igor,
>
>I'd like to stick with the jboss tm and add the needed functionality.
>
>Can you outline what you have been thinking of?
I want to allow resource manager specific variation of XAResource state
>>>
change sequence. This way we'll decouple different RMs from each other
and developers will be able to concentrate on one RM without concerns
>>>
>>to
>>
break others. I have very brief idea how this can be implemented, but I
>>>
believe it is doable and not too complicated.
>>>
>>>
>>>I'd like to see what you have in mind.
>>
>>I'm thinking about creating xa resource handlers responsible for making
>>calls on xa resources. TransactionImpl will keep track of all xa
>>resources involved into the transaction but will delegate "real" xa work
>>to the appropriate handler. These handlers will implement interface
>>something like:
>>
>>interface XAResourceHandler {
>> void commit(TransactionImpl tx) throws ...;
>> boolean delistResource(TransactionImpl tx, int flag) throws ...;
>> boolean enlistResource(TransactionImpl tx) throws ...;
>> void rollback(TransactionImpl tx) throws ...;
>>}
>>
>>We will provide DefaultXAResourceHandler which will work with ideal xa
>>resource implementations but will allow registration of rm specific
>>implementations which will support whatever crazy logic in necessary to
>>work with the rm.
>>
>>Obviously I do not know all implementation details yet but I am pretty
>>sure that it will not complicate our code much. Unfortunately I do not
>>know when I'll be able to implement it.
>
>
> This looks like it would work, but I don't see why this would be better
> than implementing specific XAResource wrappers for the bizarre XAResource
> implementations. I'm thinking
>
> txImpl calls say XAWrapper.start(xid, TMRESUME)
>
> and XAWrapper says, hmmm I don't support resume, I'll get a new branch on
> this tx and call BizarroXAResource.start(newXid, TMJOIN).
>
> I think with either approach their may be problems keeping track of all the
> modifications. Anyway I wonder if you have thought of this and know of
> problems with it.
>
> thanks
> david jencks
Sometimes we going to need transaction context (list of all xa resources
enlisted into tx and their statuses) to make correct xa call. For
example, some rm require xares.start(TMJOIN) when second connection from
the same rm joins the transaction while other support
xares.start(TMNOFLAGS) only and I am sure there are rms that support both.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
On 2002.10.03 22:12:42 -0400 Igor Fedorenko wrote:
> David Jencks wrote:
> > On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
> >
> >>David Jencks wrote:
> >>
> >>>Hi Igor,
> >>>
> >>>I'd like to stick with the jboss tm and add the needed functionality.
> >>>
> >>>Can you outline what you have been thinking of?
> >>
> >>I want to allow resource manager specific variation of XAResource state
>
> >>change sequence. This way we'll decouple different RMs from each other
> >>and developers will be able to concentrate on one RM without concerns
> to
> >>break others. I have very brief idea how this can be implemented, but I
>
> >>believe it is doable and not too complicated.
> >
> >
> > I'd like to see what you have in mind.
> I'm thinking about creating xa resource handlers responsible for making
> calls on xa resources. TransactionImpl will keep track of all xa
> resources involved into the transaction but will delegate "real" xa work
> to the appropriate handler. These handlers will implement interface
> something like:
>
> interface XAResourceHandler {
>void commit(TransactionImpl tx) throws ...;
>boolean delistResource(TransactionImpl tx, int flag) throws ...;
>boolean enlistResource(TransactionImpl tx) throws ...;
>void rollback(TransactionImpl tx) throws ...;
> }
>
> We will provide DefaultXAResourceHandler which will work with ideal xa
> resource implementations but will allow registration of rm specific
> implementations which will support whatever crazy logic in necessary to
> work with the rm.
>
> Obviously I do not know all implementation details yet but I am pretty
> sure that it will not complicate our code much. Unfortunately I do not
> know when I'll be able to implement it.
This looks like it would work, but I don't see why this would be better
than implementing specific XAResource wrappers for the bizarre XAResource
implementations. I'm thinking
txImpl calls say XAWrapper.start(xid, TMRESUME)
and XAWrapper says, hmmm I don't support resume, I'll get a new branch on
this tx and call BizarroXAResource.start(newXid, TMJOIN).
I think with either approach their may be problems keeping track of all the
modifications. Anyway I wonder if you have thought of this and know of
problems with it.
thanks
david jencks
>
> >
> >
> >>>Also, is the new xa wrapper in cvs HEAD working well enough to move to
> >>
> >>3.2?
> >>
> >>>Should we even move it to 3.0?
> >>
> >>What do you think about cached javax.jdbc.XAConnection.getConnection()
> >>problem I've mentioned few days ago? Can we afford saying "Oracle 8i is
>
> >>not supported in XA mode"?
> >
> >
> > I don't know... saying it isn't supported might be better than all the
> > problems people are having.
> >
> > Do you think it is ok to get a new Connection from the XAConnection
> > whenever associateConnection is called? If we can do this, it wouldn't
> be
> > too hard to change. I'm still mystified as to how Oracle can tell how
> many
> > Connection handles we are using and how it can decide to object.
>
> Well, most likely I misinterpreted the behaviour I've observed ;-) I
> believe oracle 8i should work fine with TrackConnectionByTx.
>
> --
> Igor Fedorenko
> Think smart. Think automated. Think Dynamics.
> www.thinkdynamics.com
>
>
>
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
David Jencks wrote:
> On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
>
>>David Jencks wrote:
>>
>>>Hi Igor,
>>>
>>>I'd like to stick with the jboss tm and add the needed functionality.
>>>
>>>Can you outline what you have been thinking of?
>>
>>I want to allow resource manager specific variation of XAResource state
>>change sequence. This way we'll decouple different RMs from each other
>>and developers will be able to concentrate on one RM without concerns to
>>break others. I have very brief idea how this can be implemented, but I
>>believe it is doable and not too complicated.
>
>
> I'd like to see what you have in mind.
I'm thinking about creating xa resource handlers responsible for making
calls on xa resources. TransactionImpl will keep track of all xa
resources involved into the transaction but will delegate "real" xa work
to the appropriate handler. These handlers will implement interface
something like:
interface XAResourceHandler {
void commit(TransactionImpl tx) throws ...;
boolean delistResource(TransactionImpl tx, int flag) throws ...;
boolean enlistResource(TransactionImpl tx) throws ...;
void rollback(TransactionImpl tx) throws ...;
}
We will provide DefaultXAResourceHandler which will work with ideal xa
resource implementations but will allow registration of rm specific
implementations which will support whatever crazy logic in necessary to
work with the rm.
Obviously I do not know all implementation details yet but I am pretty
sure that it will not complicate our code much. Unfortunately I do not
know when I'll be able to implement it.
>
>
>>>Also, is the new xa wrapper in cvs HEAD working well enough to move to
>>
>>3.2?
>>
>>>Should we even move it to 3.0?
>>
>>What do you think about cached javax.jdbc.XAConnection.getConnection()
>>problem I've mentioned few days ago? Can we afford saying "Oracle 8i is
>>not supported in XA mode"?
>
>
> I don't know... saying it isn't supported might be better than all the
> problems people are having.
>
> Do you think it is ok to get a new Connection from the XAConnection
> whenever associateConnection is called? If we can do this, it wouldn't be
> too hard to change. I'm still mystified as to how Oracle can tell how many
> Connection handles we are using and how it can decide to object.
Well, most likely I misinterpreted the behaviour I've observed ;-) I
believe oracle 8i should work fine with TrackConnectionByTx.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote: > David Jencks wrote: > > Hi Igor, > > > > I'd like to stick with the jboss tm and add the needed functionality. > > > > Can you outline what you have been thinking of? > I want to allow resource manager specific variation of XAResource state > change sequence. This way we'll decouple different RMs from each other > and developers will be able to concentrate on one RM without concerns to > break others. I have very brief idea how this can be implemented, but I > believe it is doable and not too complicated. I'd like to see what you have in mind. > > > Also, is the new xa wrapper in cvs HEAD working well enough to move to > 3.2? > > Should we even move it to 3.0? > What do you think about cached javax.jdbc.XAConnection.getConnection() > problem I've mentioned few days ago? Can we afford saying "Oracle 8i is > not supported in XA mode"? I don't know... saying it isn't supported might be better than all the problems people are having. Do you think it is ok to get a new Connection from the XAConnection whenever associateConnection is called? If we can do this, it wouldn't be too hard to change. I'm still mystified as to how Oracle can tell how many Connection handles we are using and how it can decide to object. thanks david jencks > > > I think there may still be issues in what xa flags we send in the > start/end > > calls, but I haven't had time to make a complete analysis. > > > > Thanks! > > > > david jencks > > > > On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: > > > >>Thank you, David. > >> > >>JBossTX still has problems with oracle (see for example #614116 I've > >>been working on recently) and I was thinking if it worth fixing or we > >>can switch to Tyrex. I have a solution that will solve JBossTX > >>compatibility problems once and forever, however this solution is not > >>trivial to implement and I am looking for alternatives. > >> > >>David Jencks wrote: > >> > >>>jboss tm -- fast. Does not handle distributed (multiple jboss > >> > >>instances) > >> > >>>tx. Does not do tx logging, so automated recovery is not really > >> > >>possible. > >> > >>>tyrex tm -- does handle distributed tx and logging. > >>> > >>>both will handle xa transactions with many participants where there is > >> > >>only > >> > >>>one tm instance and nothing crashes. > >>> > >>>If you need distributed tx (several cooperating tm) or automatic > >> > >>recovery > >> > >>>use tyrex. > >>> > >>>The "distributed" part is nearly done in jboss 4 for the jboss tm: as > >> > >>part > >> > >>>of the jca 1.5 support there is a tx import facility. We just need an > >>>invoker that has an XAResource in the client half and uses the Work > >>>interfaces in the server half. > >>> > >>>AFAIK no one is working on the logging part, but I don't see why it > >> > >>should > >> > >>>be hard. > >>> > >>>With logging in place I would expect automatic recovery to be fairly > >> > >>simple > >> > >>>also but I haven't thought about it much. > >>> > >>>david jencks > >>> > >>> > >>>On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: > >>> > >>> > Hi, > > Could somebody give brief comparison JBossTX and Tyrex transaction > manager and explain when I should prefer one over another? Thanks in > advance. > >>> > >>-- > >>Igor Fedorenko > >>Think smart. Think automated. Think Dynamics. > >>www.thinkdynamics.com > >> > >> > >> > >>--- > >>This sf.net email is sponsored by:ThinkGeek > >>Welcome to geek heaven. > >>http://thinkgeek.com/sf > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
David Jencks wrote: > Hi Igor, > > I'd like to stick with the jboss tm and add the needed functionality. > > Can you outline what you have been thinking of? I want to allow resource manager specific variation of XAResource state change sequence. This way we'll decouple different RMs from each other and developers will be able to concentrate on one RM without concerns to break others. I have very brief idea how this can be implemented, but I believe it is doable and not too complicated. > Also, is the new xa wrapper in cvs HEAD working well enough to move to 3.2? > Should we even move it to 3.0? What do you think about cached javax.jdbc.XAConnection.getConnection() problem I've mentioned few days ago? Can we afford saying "Oracle 8i is not supported in XA mode"? > I think there may still be issues in what xa flags we send in the start/end > calls, but I haven't had time to make a complete analysis. > > Thanks! > > david jencks > > On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: > >>Thank you, David. >> >>JBossTX still has problems with oracle (see for example #614116 I've >>been working on recently) and I was thinking if it worth fixing or we >>can switch to Tyrex. I have a solution that will solve JBossTX >>compatibility problems once and forever, however this solution is not >>trivial to implement and I am looking for alternatives. >> >>David Jencks wrote: >> >>>jboss tm -- fast. Does not handle distributed (multiple jboss >> >>instances) >> >>>tx. Does not do tx logging, so automated recovery is not really >> >>possible. >> >>>tyrex tm -- does handle distributed tx and logging. >>> >>>both will handle xa transactions with many participants where there is >> >>only >> >>>one tm instance and nothing crashes. >>> >>>If you need distributed tx (several cooperating tm) or automatic >> >>recovery >> >>>use tyrex. >>> >>>The "distributed" part is nearly done in jboss 4 for the jboss tm: as >> >>part >> >>>of the jca 1.5 support there is a tx import facility. We just need an >>>invoker that has an XAResource in the client half and uses the Work >>>interfaces in the server half. >>> >>>AFAIK no one is working on the logging part, but I don't see why it >> >>should >> >>>be hard. >>> >>>With logging in place I would expect automatic recovery to be fairly >> >>simple >> >>>also but I haven't thought about it much. >>> >>>david jencks >>> >>> >>>On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: >>> >>> Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. >>> >>-- >>Igor Fedorenko >>Think smart. Think automated. Think Dynamics. >>www.thinkdynamics.com >> >> >> >>--- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
Hi Igor, I'd like to stick with the jboss tm and add the needed functionality. Can you outline what you have been thinking of? Also, is the new xa wrapper in cvs HEAD working well enough to move to 3.2? Should we even move it to 3.0? I think there may still be issues in what xa flags we send in the start/end calls, but I haven't had time to make a complete analysis. Thanks! david jencks On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: > Thank you, David. > > JBossTX still has problems with oracle (see for example #614116 I've > been working on recently) and I was thinking if it worth fixing or we > can switch to Tyrex. I have a solution that will solve JBossTX > compatibility problems once and forever, however this solution is not > trivial to implement and I am looking for alternatives. > > David Jencks wrote: > > jboss tm -- fast. Does not handle distributed (multiple jboss > instances) > > tx. Does not do tx logging, so automated recovery is not really > possible. > > > > tyrex tm -- does handle distributed tx and logging. > > > > both will handle xa transactions with many participants where there is > only > > one tm instance and nothing crashes. > > > > If you need distributed tx (several cooperating tm) or automatic > recovery > > use tyrex. > > > > The "distributed" part is nearly done in jboss 4 for the jboss tm: as > part > > of the jca 1.5 support there is a tx import facility. We just need an > > invoker that has an XAResource in the client half and uses the Work > > interfaces in the server half. > > > > AFAIK no one is working on the logging part, but I don't see why it > should > > be hard. > > > > With logging in place I would expect automatic recovery to be fairly > simple > > also but I haven't thought about it much. > > > > david jencks > > > > > > On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: > > > >>Hi, > >> > >>Could somebody give brief comparison JBossTX and Tyrex transaction > >>manager and explain when I should prefer one over another? Thanks in > >>advance. > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
Work with David to implement compatible behavior in JBossTX. I don't want to be working through an external codebase for something as fundamental as transaction management. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Igor Fedorenko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 27, 2002 8:05 AM Subject: Re: [JBoss-dev] JbossTX vs. Tyrex > Thank you, David. > > JBossTX still has problems with oracle (see for example #614116 I've > been working on recently) and I was thinking if it worth fixing or we > can switch to Tyrex. I have a solution that will solve JBossTX > compatibility problems once and forever, however this solution is not > trivial to implement and I am looking for alternatives. > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
Thank you, David. JBossTX still has problems with oracle (see for example #614116 I've been working on recently) and I was thinking if it worth fixing or we can switch to Tyrex. I have a solution that will solve JBossTX compatibility problems once and forever, however this solution is not trivial to implement and I am looking for alternatives. David Jencks wrote: > jboss tm -- fast. Does not handle distributed (multiple jboss instances) > tx. Does not do tx logging, so automated recovery is not really possible. > > tyrex tm -- does handle distributed tx and logging. > > both will handle xa transactions with many participants where there is only > one tm instance and nothing crashes. > > If you need distributed tx (several cooperating tm) or automatic recovery > use tyrex. > > The "distributed" part is nearly done in jboss 4 for the jboss tm: as part > of the jca 1.5 support there is a tx import facility. We just need an > invoker that has an XAResource in the client half and uses the Work > interfaces in the server half. > > AFAIK no one is working on the logging part, but I don't see why it should > be hard. > > With logging in place I would expect automatic recovery to be fairly simple > also but I haven't thought about it much. > > david jencks > > > On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: > >>Hi, >> >>Could somebody give brief comparison JBossTX and Tyrex transaction >>manager and explain when I should prefer one over another? Thanks in >>advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JbossTX vs. Tyrex
jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The "distributed" part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: > Hi, > > Could somebody give brief comparison JBossTX and Tyrex transaction > manager and explain when I should prefer one over another? Thanks in > advance. > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JbossTX vs. Tyrex
Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
