Bugs item #1068322, was opened at 2004-11-17 22:39 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1068322&group_id=22866
>Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Rejected >Priority: 5 Submitted By: saro (saroramki) >Assigned to: Adrian Brock (ejort) Summary: Txn bug-Jboss3.2.3,when there is > 2 beans in the flow Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Adrian Brock (ejort) Date: 2004-11-23 15:15 Message: Logged In: YES user_id=9459 1) There is little point posting bug reports against 3.2.3 You need to first test against the latest release (3.2.6 at time of writing) 2) This is not CMP, you are using hibernate. 3) The change you are describing is a change to your transaction assembly. It sounds to me like hibernate is caching the writes to the db and hasn't reached a point where it will flush/synchronize with the db (usually transaction end or running a query). I would recommend the following approach to solving your problem: a) Understand your transaction assembly - i.e. where is the transaction committed, which hibernate sessions/db connections are part of that transaction (or transactions) b) Understand where hibernate is updating the db If you want JBoss to look at your problem, we will need an example application that demonstrates the problem against the latest release. BUG REPORTS ARE NOT THE VEHICLE TO GET HELP USE THE FORUMS at http://www.jboss.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1068322&group_id=22866 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
