You have to draw the workflow and note what primary key/tx intersections there are to determine the contention. If everything is marked as Required, then each top level session access by a web page starts a new jta tx with a independent session bean. There is no contention at this point. For every entity bean touched by the session, there is a tx lock, so that if all 100 sessions are hitting the same entity beans then the bean is locked for the duration of the top level session bean invocation.
Any contention will degrade performance. You can use RequiresNew and read-only to minimize the extent of the tx lock on entity data that is read-only or even read-mostly. You can use instance per transaction container configuration to make copies of the entity data that has no tx lock. You can use a custom locking policy that thumbs its nose at the ejb spec and does no locking at all.
It all comes down to looking at the workflows and identifying where you can relax the strict pessimistic locking.
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
Brian McSweeney wrote:
Hi Scott,
Thanks for your patience and help.
Yep, I understand that there's no such thing as web page locking, but let me put it another simpler way:
Imagine a web page that views 100 records of a database
The web page calls a method on a session façade to view those 100 records.
This method has transaction ="Required"
Now if there are 100 users simultaneously trying to access this web page
they will have to do this in a non-concurrent, serialized way. Ie, each one will have to wait for someone else to give up the transaction lock.
a) Is this correct?
b) does this significantly degrade performance.
Thanks very much, Brian
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
