This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
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?