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
>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 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 conte
>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 control
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 relea
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 b
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
> 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 s
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
uld see them when 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, Ba
-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
.
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
.
>
> 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?
--
xxx
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 about MDB retry implementations. I was
expecting the retry of the message to be in the same thread as the one that
origina
TECTED]
14.08.2003 22:33
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 "rea
?
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 not the s
message at a time as long
as there isn't a container transaction 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
he
source queue 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 Single
arrival not the nack).
Regards,
Adrian
> 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
>
> That isn't the wa
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
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 nacked the failed message back into the queue, it will
process the waiting message using the freed session.
It will then as
I have a singleton CMT MDB consuming on a JMS queue with a retry threshold
set to 3 attempts. I made the assumption that no other messages on the
queue would be consumed until the current message being processed either
finishes and is consumed, or in the event of a container transaction
rollback a
22 matches
Mail list logo
