[ http://jira.jboss.com/jira/browse/JBAS-100?page=comments#action_12310856 ] SourceForge User commented on JBAS-100: ---------------------------------------
SourceForge Username: nobody . Logged In: NO That's a possible solution, but there's a more general one, which also needs less work in the clients (session beans). That is to provide an alternative TransactionManager, which is capable of using optimistic scheduling instead of two- phase commit. It could cooperate with an abstract MultiVersionEntityBean. The result would be like this. Read only transactions (queries) occur without any locking, and read the status of the entities after the last committed transaction. When another write transaction commits, previous versions of entity values can be discarded, if there are no pending queries. Update transactions procede without locking, and create new versions of entity values. When a transaction commits, the TM checks that the current transactions are orderable into a sequence. If so, commit procedes. If not, the deadlock is resolved by aborting one or more transactions (favouring the least recent to start). This technique often gives better performance. The tricky bit is to make it work with clustering, but there are published papers that help. Anyone interested in collaborating on this is welcome to email me at [EMAIL PROTECTED] > 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
