On 28 Maj, Vincent Harcq wrote:
> Hi,
> After implementing MDB in ejbdoclet, one of the developer find out
> that jboss does not follow the spec for <acknowledge-mode> on MDB.
> Page 462:
> <!--
> The acknowledge-mode element specifies whether JMS AUTO_ACKNOWLEDGE
> or DUPS_OK_ACKNOWLEDGE message acknowledgment semantics should be
> used for the onMessage message of a message-driven bean that uses bean
> managed transaction demarcation.
> The acknowledge-mode element must be one of the two following:
> <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
> <acknowledge-mode>Dups-ok-acknowledge</acknowledgemode>
> Used in: message-driven
> -->
>
> So - for MDB and _ for JMS
>
> Stupidity of the spec maybe, but we need to change jboss to have full
> compliance. I can commit the change and I propose to keep both
> possibilities for safety.
>
Well, I don't think it is that easy. First we had support for it. Then
Hiram added support for XA transactions in JBossMQ and added support for
that in the MDB container, but broke support for ACK modes. We had some
arguing about this, and finally decided that we did not need to support
DUPS_OK_ACKNOWLEDGE.
Was this bad or god? Well, I would interpret it this way.
1. With bean managed transaction we support AUTO_ACKNOWLEDGE semantics,
i.e every message is automtically acked. Yes, we are doing it with a
transacted session, but that is an implementation question and
nothing else (who cares that non XA transactions in JBossMQ is
actually managed with single commit XA transactions under the hood?
2. DUP_OK. To my knowledge this is a flag that the JMS provider MAY
obay (i.e it is completly up to the JMS provider how to implement
support for this - it may even be done as AUTO_ACKNOWLEDGE). What it
says is that if it is used ,the client have to be aware that there
may be some resent messages.
Therefore I would say that the MDB container is spec compliant. You may
specify AUTO_ACKNOWLEDGE or DUP_OK in the deployment descriptor, but the
implementation does not care (which in my view probably is not a breach
with the spec). If it is possible to show that DUPS_OK if used could
lead to dramatic increase in performance, that would be another
question.
That to say, if you are able enough to reimplement support for DUPS_PK
without braking anything, please go ahead.
//Peter
> Vincent.
>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
--
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
