[ http://jira.jboss.com/jira/browse/JBAS-100?page=comments#action_12310857 ] SourceForge User commented on JBAS-100: ---------------------------------------
SourceForge Username: che--- . Logged In: YES user_id=455149 Hi Folks, worried about the locking policys in JBoss 2.4.x and later in 3.0.x, we have written our own policy which implements a writer prefered reader/writer-lock (using the concurrent package), depending on which methods are invoked (reads can be done concurrently while writes are exclusive). It works fine under JBoss 2.4.x on a system with a really very high load and i have ported with to 3.0.x. If anyone have interest on details mail me. > Intelligent Locking > ------------------- > > Key: JBAS-100 > URL: http://jira.jboss.com/jira/browse/JBAS-100 > Project: JBoss Application Server > Type: Feature Request > Reporter: SourceForge User > Assignee: Scott M Stark > > > SourceForge Submitter: nobody . > 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] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
