Txn bug-Jboss3.2.3,when there is > 2 beans in the flow

SourceForge Submitter: saroramki .
Opearating system : windows-xp professional
JDK version : J2sdk1.4.2_03
JBoss version : 3.2.3

APPROACH 1:
==========

There is a bean say B1, it is a SSB (Stateless Session
Bean) with a txn set for RequiresNew for all of its
method.
From this B1, when a call goes, it flows thru quite a few
classes, all of them are POJO's (Plain Old Java Object).
For our discussion let us take there is one class
say Pojo1.
Finally on the data layer , there is a bean say D1, it is a
SSB (Stateless Session Bean) with a txn set for
Required for all of its method.

From the business tier(from POJO's), it makes multiple
calls here and there to data layer.
At the data layer, for each request, a hibernate session
is created and closed.

For the B1's one particular method execution, Pojo1's 2
different method gets
called one after another.In the Pojo1's first method call,
it writes a record in to
a table by calling D1's one particular method. In the
Pojo1's second method call,
it looks for this new record that has been written by the
first method call,
after getting this record,it does some job per biz need.

In the above setup, when there is a total of 2 beans(B1
on biz and D1 on data layer)
involved, everything works fine. In specfic, Pojo1's 2nd
method call could get the
record written by its first method call. Or in other words,
this new record,
which is still not visible to the outside world, is visible to
the the Pojo1's
2nd method call, which is the right transaction
behaviour..

Everything looks fine and working fine in this Approach 1
Now we thought of doing a resturcuturing and introduce
one another bean layer in
between B1 and D1.This is described as below.

APPROACH 2:
==========

Consider the same above Approach 1, but after B1, the
call would go to one another
bean A1(bean for the new app service layer), it is a SSB
(Stateless Session
Bean) with a txn set for Required for all of its method.
Instead of B1 taking to Pojo1 as in approach1, here B1
would talk to A1 and
A1 would talk to Pojo1 and Pojo1 to D1.

The purpose of introducing A1 is to meet some of our
business needs +
at A1, get a hibernate session and attach it to the
thread local, and modify all
data layer methods, to get hibernate session from
thread local and don't close the
hibernate session at the data layer level. Plus roll back
the transaction at this
A1, if there is any exception caught.Close the hibernate
session in its(i.e at A1)
finally.

Now with the 3 beans in the entire flow, during the
second method call of the Pojo1,
it couldn't able to see the record written by its first
method call, so we run in
to our biz exception.

I tried with all different transaction types for this
particular method of A1 to see what is going on,none of
them worked.

What I'm wondering is, can't Jboss transaction handle 3
SSB's in a flow with the above described way

Looks to me it is clearly a bug.

If this is a known bug in 3.2.3 and if it is fixed in any of
the further releases, pls let me know.
Else if this has been never brought up,then it is a
serious trouble for JBoss users out there in the market,
means it should be fixed asap.

Please let me know if you need more explanation.

Thanks
Saro