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
inv
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 w
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 de
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 o
>
> 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
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 only
Can you describe this "basic stuff" a little? I am considering
implementing distributed tx. I looked into the code and I have some
implementation ideas in mind, but I would like to know what is your
plan here and I definitely do not want to repeat something that is
already done.
So far it
> 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 s
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 serie
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 a
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?
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 call
> 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 wou
> 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
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
ge-
> >> From: marc fleury [mailto:[EMAIL PROTECTED]]
> >> Sent: Wednesday, January 15, 2003 6:37 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: RE: [JBoss-dev] Transaction propagation change
> >>
> >>
> >> one of my favorite topics is comin
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 frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH
RESPECT TO
TRANSACTION. Yeah I know the answer you could have a lon
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 res
> 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
> 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
> > 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
> > b
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 is
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
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
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 wrot
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 :)
>
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 becau
> 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 fra
> 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
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
on the definition of a web
transaction.
IN fact it is a requisite for web services (generic way)Tx definitions.
Many threads TX!
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
> > 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)
> 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 mulitpli
> -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. mul
iram
>
> > -Original Message-
> > From: [EMAIL 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
&
> 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
> w
]]
> 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 frankly WHY DO WE CARE THAT MESSAGING
> 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 b
on the definition of a web
transaction.
IN fact it is a requisite for web services (generic way)Tx definitions.
Many threads TX!
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of danch
Sent: Wednesday, January 15, 2003 6:18 PM
To: [EMAIL PROTECTED]
Tx definitions.
>
> Many threads TX!
>
>
>
> marcf
>
> > -----Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On
> > Behalf Of danch
> > Sent: Wednesday, January 15, 2003 6:18 PM
> > To: [EMAIL PROTECTED]
> > Su
ROTECTED]] 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
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.
>
&g
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 to
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 jbo
n semantic of NEVER in the ejb-jar.xml).
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
4:19 AM
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 abou
3 4:19 AM
> 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
&g
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 ma
48 matches
Mail list logo
