On Tuesday, January 21, 2003, at 01:27 AM, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
interceptor
that does distributed tx stuff that you've described but in invoker
independent way?
If
Dunno yet, first I have to finish it:-)
It uses the jca 1.5 interfaces pretty heavily, so it might be
a fairly
large change. However desirable it might be, realistically
speaking, I
probably won't backport it unless someone pays me.
Fair enough. Maybe I can arrange to have you
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
interceptor
that does distributed tx stuff that you've described but in invoker
independent way?
If only ole
On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote:
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
interceptor
that does distributed tx stuff that you've
On Tue, 21 Jan 2003, David Jencks wrote:
On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote:
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
On Tuesday, January 21, 2003, at 02:17 PM, Francisco Reverbel wrote:
On Tue, 21 Jan 2003, David Jencks wrote:
On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote:
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
On Thursday, January 16, 2003, at 09:57 PM, Barlow, Dustin wrote:
the only reason is that no one has previously written a
distributed tx
manager. I wrote the basic stuff we need in jboss 4, it should even
work with the trunk invoker.
david jencks
Can this be back ported to the 3.x series?
On Sunday, January 19, 2003, at 10:00 AM, Igor Fedorenko wrote:
David Jencks wrote:
On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote:
Let me simplify the example to demonstrate my real point. (and
hopefully
this is a better example)
In the 3.x series of JBoss, there isn't
David Jencks wrote:
On Sunday, January 19, 2003, at 10:00 AM, Igor Fedorenko wrote:
David Jencks wrote:
On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote:
Let me simplify the example to demonstrate my real point. (and
hopefully
this is a better example)
In the 3.x
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
interceptor
that does distributed tx stuff that you've described but in invoker
independent way?
If only ole husgaard was awake :)
I have been asking the same
David Jencks wrote:
On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote:
Let me simplify the example to demonstrate my real point. (and hopefully
this is a better example)
In the 3.x series of JBoss, there isn't a way to have one SSB with a
transaction attribute of Required
]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction through asynchronous transports doesn't sound like a good
idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small correction
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one thread adds 2, the other
thread mulitplies by
I think you're talking about giving people something more like
asynchronous method invocations (one-way) than traditional MOM style
messages, right?
I am talking about propagation of TX with async calls, yes.
An asynch. invocation on the other hand, ought to take the
transaction
with
PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
marc fleury
Sent: Wednesday, January 15, 2003 6:37 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Transaction propagation change
one of my favorite topics is coming up again
One day I will sit down and write a tx spec.
Ok
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Sacha Labourey
Sent: Thursday, January 16, 2003 9:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Transaction propagation change
1. multiple threads in one tx. This is doable
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one thread adds 2, the other
thread mulitplies
But to do this you need a way to create a thread in a
transaction-friendly way i.e. if you simply create a new
thread (t = new Thread), then new correct transactional
context is associated with this newly started thread. Correct?
inheritableThreadLocal (or something like that)
Yes, but
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction
Dustin,
I am sorry I went on a tangent, it is just a pet peeve of mine for the
longest time (and I still have to hear about OLE, who likes these
discussions ;).
In the 3.x series of JBoss, there isn't a way to have one SSB
with a transaction attribute of Required call another SSB
with a
guess it simply comes down to the fact that since the
beginning we hear in specs: threads are bad, bouh! , thus
it has never been standardized and instead we have to use
3000 lines of JMS + MDB to simulate async behaviour in containers.
well what you want is a language level construct a la
In fact we could TOTALLY do that on the new AOP framework. If you
define with an xdoclet tag that a given method is @jboss:one-way then
we put an interceptor that takes fresh thread and returns immediately.
Me likes.
Please check out the metadata stuff I've been doing for the AOP
Sacha Labourey wrote:
+
I guess this is the whole point: current JMS transactional behaviour is fine
as long as what you want is *really* to decouple the producer from the
consumer, but when what you want is just transactional multithreaded, then
it is no more (and by far) a good solution because
My answers/comments are inline:
I am sorry I went on a tangent, it is just a pet peeve of mine for the
longest time (and I still have to hear about OLE, who likes these
discussions ;).
No need to apologize at all. I think it's an interesting topic as well.
Plus you're the boss so :)
In
If I understand you right, you're asking to propagate transactions via
JMS messages because they're not propagated via non-local EJB calls. I
think that begs the question, doesn't it?
Meanwhile the conversation has gone on to (basically) asynchronous EJB
(really AOP) calls.
Barlow, Dustin
marc fleury wrote:
The original point was that JMS allows you transact the
message put. If the message put is part of the global unit
of work and it has not committed, then no receiver can pick
up the message (the put does not actually occur till we
commit). This really has VERY little to
Barlow, Dustin wrote:
That is what I contest. Why ? So what if it is persistent/async?
theoretically speaking what is the limitation here?
because if you care about the transaction, JMS is the wrong tool.
There's no theoretical limitation, but if what you want to to execute an
asynchrounous
Dustin,
Please don't take offense here, but you seem to be heading in a couple
of directions where, based on my experience, I think you'll hit some
problems. Apologies in advance if I've misunderstood.
Barlow, Dustin wrote:
My answers/comments are inline:
I am sorry I went on a tangent, it
I guess this is the whole point: current JMS transactional
behaviour
is fine as long as what you want is *really* to decouple
the producer
from the consumer, but when what you want is just transactional
multithreaded, then it is no more (and by far) a good solution
because you
transaction attribute of NEVER on both ejbs). I think this
is exactly what Scott was addressing in his original post,
that at a bare minium, we should have the ability to say, we
don't want and can't have the transaction context pushed to
the node, so don't even try. Of course this does
No the crux of the problem is that JMS was designed to
address the needs
of providers of application integration infrastructure that's
used for
loosely coupled interfaces between systems. If you're loosely coupled
enough to use JMS, you don't want the transaction propagated.
it is a
On Thursday, January 16, 2003, at 09:27 AM, Sacha Labourey wrote:
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate
-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction through asynchronous transports doesn't sound
like a good
idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small correction.. your example would have
]] On
Behalf Of
danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a transaction through asynchronous transports doesn't
sound
like a good
That is easy. SPEED. Distributed transaction are pricey and difficult.
By choice we did fastTM as an InVM implementation. Typical case of
90/10. Most applications actually use only invm stuff and so having an
implemetnation that serializes stuff back and forth isn't worth it.
Right now FastTM
Dustin,
Please don't take offense here, but you seem to be heading in
a couple
of directions where, based on my experience, I think you'll hit some
problems. Apologies in advance if I've misunderstood.
I never take offense to constructive criticisms/comments, I learn from them,
so no
the only reason is that no one has previously written a
distributed tx
manager. I wrote the basic stuff we need in jboss 4, it should even
work with the trunk invoker.
david jencks
Can this be back ported to the 3.x series? I'm mostly interested in the
3.2, but i presume it would
).
Dustin
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 9:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
On Monday, January 13, 2003, at 08:58 AM, Barlow, Dustin wrote:
Will this fix also
Just a small correction.. your example would have to be in at least 2 units
of work. There is NO WAY to put a JMS message and get it again in a single
transaction.
Regards,
Hiram
Having a distributed transaction context is especially important
for example
when you have a EJB from one jboss
And having a way to do that would probably be a Bad Idea. Propogating a
transaction through asynchronous transports doesn't sound like a good
idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small correction.. your example would have to be in at least 2 units
of work. There is NO WAY
] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction through asynchronous transports doesn't sound like a good
idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small correction.. your example would have
:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Transaction propagation change
And having a way to do that would probably be a Bad Idea.
Propogating a
transaction through asynchronous transports doesn't sound like a good
idea to me, anyway.
-danch
Hiram Chirino wrote:
Just a small
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Transaction propagation change
Regarding bug: [ 663114 ] MarshallException when accessing
remote bean, this is
due to a change made to store the transaction context of an
Invocation in the as_is_payload
rather than the transient_payload map about
Regarding bug: [ 663114 ] MarshallException when accessing remote bean, this is
due to a change made to store the transaction context of an Invocation in the
as_is_payload
rather than the transient_payload map about the time of the 3.0.0 release. Our tx
info never has been serializable, and the
45 matches
Mail list logo
