Feature Requests item #444258, was opened at 2001-07-24 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=444258&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Intelligent Locking Initial Comment: There is a serious drawback I have seen in the WebLogic 6.0 locking model. You have several choices: 1) Exclusive Locking (the entity EJB can only be used by one caller at a time whether the method be called is transactional or not) 2) Database Locking (the backing datastore is used to provide the locking and multiple entity EJB instances are used to represent the same entity while providing single-client access to each at any given time) 3) Read Only (the object doesn't change so no locking is needed) Model (1) is sloooooow because you obtain an exclusive lock even when calling non-transactional methods (like "getFirstName()") in a non-transactional context. Model (2) is bad because I do all of my database access in ejbStore(). If I have a Person entity EJB with an "email" and "firstName" property I can have the following scenario: 1) Client A accesses Person with ID=1 and updates the first name by calling "setFirstName(String)" 2) Client B accesses Person with ID=1 and updates the e-mail by calling "setEmail(String)" 3) The ejbStore() method is called on Client A's entity, storing the new first name. 4) The ejbStore() method is called on Client B's entity, overwriting the new first name with the old one and storing the new e-mail. Model (3) is useless in most situations. ** BUT ** I have an idea and was wondering if JBoss might already implement this..... If an entity EJB is properly implemented then all methods that modify the EJB in some way should require a transaction in some way (either required, mandatory, or new). Suppose we used an EJB entity pool that behaved as follows. 1) Any single entity is represented by a number of NON- transactional EJB instances and a SINGLE transactional instance. 2) Access to the NON-transactional intances is freely allowed if methods are called in a state where they will not participate in a transaction. These instances never have their ejbStore() methods called since they don't change. This allows high throughput access for simple operations like "getName()" 3) If a transactional method is called by a client then the single transactional instance is exclusively locked for that client. Meanwhile the NON- transactional instances can be used by other clients that are not attempting to involving the entity in a transaction. 4) If the transaction is rolled back, the transactional instance is repopulated with data in the database (i.e.: "ejbLoad()") to reflect that the changes were not committed. 5) If the transaction commits, then container obtains a lock on all instances of the entity. This means the container places a request for an exclusive lock on all NON-transactional instances as well as the transactional instance for which it already holds the lock. 6)Once a lock is obtained on all instances, then ejbStore() is called on the transactional instance. If all succeeds without an exception then all of the NON-Transactional instances have their "ejbLoad()" method called. By calling ejbLoad(), the non- Transactional instances become aware of the changes that occurred to the transactional instance. This always seemed to me like the model that was intended when the EJB specification was written, but it has not been implemented by the folks over at BEA. I would love to see this in JBoss. I have yet to download JBoss because we need cluster and fail-over support where I work. Let me know if this seems like a good model. I wish I had the time to participate and contribute to the source base. Best of luck... -Barry M. Caceres [EMAIL PROTECTED] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=444258&group_id=22866 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
