aspose file tools*
The moose likes BEA/Weblogic and the fly likes Bean Locking Weblogic 4.5.1 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » BEA/Weblogic
Bookmark "Bean Locking Weblogic 4.5.1" Watch "Bean Locking Weblogic 4.5.1" New topic
Author

Bean Locking Weblogic 4.5.1

Nilesh Nadiyana
Greenhorn

Joined: Dec 24, 2002
Posts: 21
Hi!
Environment : Weblogic 4.5.1
We are facing bean locking problems lately (no, not because of deadlock).. I read that BEA uses Pessimistic locking approach. In the simplest case, Meaning that User1 has fetched data (say for reading) and at the same time, user 2 also needs data for reading, then until and unless user1 is finished, user2 wont get this data and the bean would remain locked.
Now, Question:
1) How do I know whether user1 has finished? ( I am assuming it has started a transaction of its own); Might be end of that procedure (say in a session bean to retrieve data from that specific entity say company based on company id?)
2) Is there a way to change this pessimistic locking to optimistic locking
a) Programmatically
a.1=> This could be like including time stamp or version. Any other way ?
b) At appserver level (any other option then Upgradation )
Your help would be highly appreciated.
Thanks in Advance.
Regards,
Nilesh.
Sergiu Truta
Ranch Hand

Joined: Dec 16, 2003
Posts: 121

Database Locking Services
Database locking is the default for WebLogic Server 6.1. It improves concurrent access for entity EJBs. The WebLogic Server container defers locking services to the underlying database. Unlike exclusive locking, the underlying data store can provide finer granularity for locking EJB data, and deadlock detection.
With the database locking mechanism, the EJB container continues to cache instances of entity EJB classes. However, the container does not cache the intermediate state of the EJB instance between transactions. Instead, WebLogic Server calls ejbLoad() for each instance at the beginning of a transaction to obtain the latest EJB data. The request to commit data is subsequently passed along to the database. The database, therefore, handles all lock management and deadlock detection for the EJB's data.
Deferring locks to the underlying database improves throughput for concurrent access to entity EJB data, while also providing deadlock detection. However, using database locking requires more detailed knowledge of the underlying datastore's lock policies, which can reduce the EJB's portability among different systems.

You can find out more at the BEA website.


...watch me...as I'm walking the path...
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Moving to the BEA/WebLogic forum...
Nilesh Nadiyana
Greenhorn

Joined: Dec 24, 2002
Posts: 21
Thank You for your Response.
Now, apart from this concurrent access problem,The Bean locking can also occur due to the high load?
Say, I have max number of possible instances of a Entitybean as 1000. but I am processing 2000 records , from multiple clients. (Assume that it's a common routine like a scheduler which gets executed for each client accessing the same set of records), Is it that such a situation can lead to bean locking?
 
jQuery in Action, 2nd edition
 
subject: Bean Locking Weblogic 4.5.1