Understanding CMT, HELP!!

Question

I'm looking for a good explanation of container managed transactions. At my company we have an EJB app in which we are trying to set CMT attributes on. It's strucured in a way that each table in our DB has a corresponding entity bean. (we use BMP entity beans) The app is already developed mostly (its in alpha) and none of us here understand enough about how to declare container transactions in a production app. We all know what they are (the six different kinds) and how they all work. What we're looking for is a practical example (not like the dumbed down textbook examples) of how you would use them in a production app. All of us here are stuck on the programmatic way of thinking and I know this is wrong when using CMT. So, this is the example. We have a submitOrder method that appears to be causing rollbacks/deadlocks (because we set every method's tx attribute to Required as a starting point). The submitOrder implementation is as follows:
submitOrder
   For Each lineItem
      lookup lineItem product
      adjust lineItem price using product
   End For
   set orderHead status finalized
end submitOrderWe have reason to believe that the rollback/deadlock comes from reading the product table from within a tx and thus locking certain product entities. The scenario goes as follows. User1 needs products A, B, and C. User2 needs products C, B, and A. When user1 reads A he is pre-empted by user2 who grabs C & B. Now user1 tries for B but has to wait for user2 who is waiting for the A that user1 has a lock on. There is no reason for the problem to occurr any place else because each user maintains his/her own set of lineItem transactions and works off of his/her own order record. So the question is this.
How would you set tx attributes to allow the method body to be in a transaction while not pulling the product entities into the transaction? 1st idea is to set the transactional attribute of the read method of the product entity to NotSupported. This is no good because there are other places in our app where we need to read the product within the context of an existing transaction. Next idea is to mark the read method on the product bean supports. However, that puts us right back where we started because the products will be read within the transaction causing deadlocks/rollbacks. So now I'm thinking that we need to call the read method on the product bean from a utility method that's marked NotSupported. But that sounds too much like programmatic tx control. So how do you address this problem? I'm looking for a best practice approach.
Cliff

Answer 1

So I need to define another entity bean just to get a non-transactional read on a product entity? Tell me there's got to be a better way. Is this the more common practice? Lets consider this scenario. I have 30 different tables in my DB. Each one has a corresponding entity bean. Lets now say that 15 of these tables need to be accessed in a read mostly fashion. Would that mean I should define an additional 15 beans to accomodate this bringing my total entity bean count to 45? This is a huge undertaken when applied to my app. We have about 170 different tables all of which have a corresponding entity bean. These beans are code-generated from the DB schema. The vast majority of them would most likely need to be read-mostly. This means that I need to code generate some extra entities to accomplish this which means more work at the code generation side. (I certainly wouldn't want to manually code them.) The scary thing is that I can't see how else to accomplish meaningful transaction isolation. I understand how complex it becomes when you start calling between methods on the same EJB and I'm frustrated by this. With POJO coding this is such a non-issue.
Lets step back and consider it on a conceptual level. I have server side logic that carries out a task on an entity. (Lets consider the entity to be abstract at this point.) 1/2 of the logic accesses other shared entities only to support the other 1/2 of the logic which represents an atomic unit of work. Logically I think of this as two separate methods. I don't think in terms of two separate objects containing the two methods because they methods relate to the same course of action, the same unit of work. You see where I'm lost here? I'm not getting the metaphore. (Please forgive me if it sounds like I'm debating with you because I'm not.) I wish I could see and understand a practical solution to this problem.
If your telling me that I need to introduce new objects for the sake of isolation then I can't see it. With POJO coding this would not be an issue, but introducing new entity beans merely to isolate a read seems excessive. Is there any better way around this? Thanks so much for your replies.
Cliff