On Sep 15, 2004, at 1:37 PM, S. Radojcin wrote:

>
>
> David Jencks wrote:
>
>>>> If you are using jms
>>>>
>>> - yes, exactly. My situation is simple:
>>>
>>> 1. one MessageDrivenBean (with 'class level' @...
>>> type="Required" tag) simply creates one entity EJB, then does
>>> transition by sending some XML message to the javax.jms.Queue
>>>
>>> At this moment, everything is ok (I hope, but to tell you truth, I
>>> nohave idea what happens at this moment with transaction, one
>>> explanation will be helpful)
>>>
>>>
>>>
>>
>> Limbo transaction later appears to mean that this transaction prepared
>> but did not commit. There ought to be something in the logs
>> indicating
>> what happened. I'd expect this problem only if jboss crashed during
>> commit.
>>
>> Hmm. Another possiblity might be that the jms message delivery is not
>> transacted? If the xml message the first mdb sends is sent outside
>> the
>> mdb's transaction, it could be received before the first transaction
>> finishes committing. How exactly is the first mdb getting the jms
>> connection factory? Are you sure this connection factory is
>> transacted?
>>
>
> - yes, I'm sure, here is statement:
>
> < ...ic.lookup() etc...>
> qConnect = qFactory.createQueueConnection();
> session = qConnect.createQueueSession(true, 0); // NOTE
> 'true' here....

I would think that this parameter should have no effect inside the
container. Check that the *-service.xml file that configures the
outbound jms adapter is configured for xa transactions.

> .........
> - but, strange thing happens. First mdb is configured for Container
> Managed Transaction, and sends message by just calling
>
> qSender.send(xmlMsg); // <==> QueueSender.send()
>
> - and nothing after that. In this case, everything is ok, no limbo tx,
> EXCEPT fact, that message simply does not arrive to the second mdb.
> Nothing, just silence. It seems like session fails to join to the CMT
> transaction; container simply does not commit them.
>
> - Because of that fact, after qSender.send() call , I decided to commit
> session manualy, by calling
>
> session.commit();

If this works, it is the cause of your problem. The new message is
getting delivered before the jta/firebird transaction commits.

>
> -With this, xml message arrives to the second mdb, but this mdb cannot
> find ejb, because of limbo transaction
> It seems like container tries to commit session, but can't do this,
> because of my own .commit() call...and voila,
> here is Firebird limbo...
>
> Very strange, I'm totaly confused... is this possible that JBoss does
> not start transaction before onMessage() method ?

I'm not an expert on transactions with jbossmq. It looks to me as if
the jta transaction is started on messaged delivery, the jaybird
connection is properly enrolled, and then it doesn't finish committing.
If you are really on jboss 3.0.8 I'd start by upgrading to 3.2.3 and
seeing if anything changes. (this will require substantial changes to
at least how to configure your firebird/jaybird connection).

I would also comment out getting the outbound jms connection and
sending the message and verify that the jta tx completes properly and
that you can see the data you expect in firebird.

david jencks

>
>
>>> 2. on the other side, second MDB (from the same .jar) which listens
>>> on
>>> the Queue, tries to find local interface of that entity EJB.
>>> And FinderExcpetion because of limbo transaction happens.
>>>
>
>
>>
>>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>