From: JD B. <br...@re...> - 2002-07-11 23:49:14
|
In looking into this further we actually have 3 layers. 1) Non-Transactional (NT) Session Beans Accessed from the client for business logic that doesn't read/write persistent objects 2) Session Facade Accessed to read/write persistent objects (and for business logic on them) 3) Entity Beans We had our NT session beans with no transattibute specified and so they had the default of Requires. Our current thinking is: NT Sessions Beans transattribute = Never Session Facade transattribute = Requires Entity Beans transattribute = Mandatory The spec doesn't allow Entity Beans to be Supports, so we shouldn't be using that, although JBoss allows it. The dependency looks like this: /-> [NT Session] --> [Session Facade] <--> [Entity] [client] / \ ------------ / The client can call into either session bean layer. The client cannot call into the entity layer. The NT layer cannot call into the entity layer. The facade cannot call into the NT layer. Does this seem like a reasonable approach? Tx, JD -----Original Message----- From: JD Brennan Sent: Wednesday, July 10, 2002 10:56 AM To: JBoss Users (E-mail) Subject: Recommended CMP Pattern for transaction management? Is there a recommended pattern for controlling transaction boundaries with CMP? We have an entity bean layer where all entity beans have transattribute = Supports And an session bean layer facade above that where all session beans have: transattribute = Required We recently switched from MySQL to MS SQL Server and have noticed an intermittent problem where a transaction never commits and the system hangs because other threads start piling up waiting for a row that is locked in the transaction that isn't committing. I'm not sure if this is a JBoss issue or if we should be doing something different with our CMP transaction semantics. Maybe we've outgrown CMP and it's time to switch to BMP?? Tx for your thoughts and insights! JD |