No it is done that way for two reasons:
1) Symmetry - JMS doesn't care that when it invokes onMessage on
the MDB container that it actually gets delivered to a pooled EJB
underneath.
The MDB either runs in the transactional context
or suspends it (Requred or NotSupported)
it never controls the
On Mon, 2003-08-18 at 19:57, Barlow, Dustin wrote:
No it is done that way for two reasons:
1) Symmetry - JMS doesn't care that when it invokes onMessage on
the MDB container that it actually gets delivered to a pooled EJB
underneath.
The MDB either runs in the transactional context
or
The transaction is started by JMS when it enlists the XASession's
XAResource. The MDB either uses it or suspends it.
When you move away from the ConnectionConsumer used in the 3.x series to the
JCA1.5 MessageEndpoint approach for the 4.x series, will the above behavior
still apply?
Dustin
On Mon, 2003-08-18 at 22:14, Barlow, Dustin wrote:
The transaction is started by JMS when it enlists the XASession's
XAResource. The MDB either uses it or suspends it.
When you move away from the ConnectionConsumer used in the 3.x series to the
JCA1.5 MessageEndpoint approach for the 4.x
On Sat, 2003-08-16 at 03:50, Barlow, Dustin wrote:
Adrian Brock wrote:
The order of work is roughly:
1) receive()
2) getSession() and enlist in tx
3) getMDB()
4) onMessage()
5) releaseMDB()
6) commitSession()
Why couldn't the commitSession() be done prior to releaseMDB()? Seems
the MDB retry
implementation in JBossMQ?
Dustin
-Original Message-
From: Adrian Brock [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 6:58 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] MDB Singleton retry semantics
So you're wait is really on the mdb pool
Bitte antworten an jboss-user
An:'[EMAIL PROTECTED] ' [EMAIL PROTECTED]
Kopie:
Thema:RE: [JBoss-user] MDB Singleton retry semantics
I guess it isn't obvious to me why is readahead important in terms of
efficiency of queue message consumption. Can you elaborate
Thanks
for the input, and yes I was aware that you cannot assume any message
ordering. What I am referring to is slightly different and I'm not sure
what the spec has aboutMDBretry implementations. I was
expecting the retry of the messageto be in the same thread as the one that
original
rollback.
BTW: I'm using JBoss 3.2.2RC2.
Dustin
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 8/14/2003 2:27 PM
Subject: RE: [JBoss-user] MDB Singleton retry semantics
How are you enforcing the singleton?
--
Adrian Brock
Director
.
Rgds,
Dan.
--
Danny Yates
-Original Message-
From: Barlow, Dustin [mailto:[EMAIL PROTECTED]
Sent: 14 August 2003 21:14
To: '[EMAIL PROTECTED] '
Subject: RE: [JBoss-user] MDB Singleton retry semantics
In conf/standardjboss.xml I setup a new invoker-proxy-binding and a
container
[mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 6:58 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] MDB Singleton retry semantics
So you're wait is really on the mdb pool not the session pool.
The session pool wait is still there.
You probably still have the default 15
it
fires.
Dustin
-Original Message-
From: Adrian Brock [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 9:55 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] MDB Singleton retry semantics
On Fri, 2003-08-15 at 13:45, Barlow, Dustin wrote:
In the invoker-proxy-binding
On Fri, 2003-08-15 at 16:38, Barlow, Dustin wrote:
Setting the MaximumSize to 1 does indeed fix the problem, or at least masks
it.
Now, this begs the question of since there is a complete rewrite of JMS in
the 4.0 series, and I am planning to upgrade from the 3.2 series to 4 series
to
JBoss4 implements the integration using JCA1.5 MessageEndpoint
The ConnectionConsumer is no longer used.
You should consider JBoss4 alpha quality software.
And I do. However, that doesn't answer the question of retry behaviour for
MDBs in 4.0. Basically will the implementation in 4.0 for
On Fri, 2003-08-15 at 19:59, Barlow, Dustin wrote:
JBoss4 implements the integration using JCA1.5 MessageEndpoint
The ConnectionConsumer is no longer used.
You should consider JBoss4 alpha quality software.
And I do. However, that doesn't answer the question of retry behaviour for
MDBs
Adrian Brock wrote:
The order of work is roughly:
1) receive()
2) getSession() and enlist in tx
3) getMDB()
4) onMessage()
5) releaseMDB()
6) commitSession()
Why couldn't the commitSession() be done prior to releaseMDB()? Seems that
if 5 and 6 were flipped, the overall behaviour would be the
How are you enforcing the singleton?
--
Danny Yates
-Original Message-
From: Barlow, Dustin [mailto:[EMAIL PROTECTED]
Sent: 14 August 2003 19:00
To: [EMAIL PROTECTED]
Subject: [JBoss-user] MDB Singleton retry semantics
I have a singleton CMT MDB consuming on a JMS queue with a
: Adrian Brock
To: [EMAIL PROTECTED]
Sent: 8/14/2003 3:11 PM
Subject: Re: [JBoss-user] MDB Singleton retry semantics
That isn't the way it currently works.
The ConnectorConsumer immediatley retrieves the next message
from the queue then waits for a ServerSession from the pool.
Once you've
again, this still wouldn't guarantee that other messages
wouldn't be in front of that reposted message correct?
Thanks for the help,
Dustin
-Original Message-
From: Adrian Brock
To: [EMAIL PROTECTED]
Sent: 8/14/2003 3:11 PM
Subject: Re: [JBoss-user] MDB Singleton retry semantics
PROTECTED]
Sent: 8/14/2003 2:27 PM
Subject: RE: [JBoss-user] MDB Singleton retry semantics
How are you enforcing the singleton?
--
Danny Yates
-Original Message-
From: Barlow, Dustin [mailto:[EMAIL PROTECTED]
Sent: 14 August 2003 19:00
To: [EMAIL PROTECTED]
Subject: [JBoss-user] MDB
20 matches
Mail list logo
