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
