Performance and scalability: Concurrency problem while using EJB's
Hi i am using a web application using Session beans, the backend database is SQL Server.All my transactions are written within SQL procedures. My session beans access plain java pojos which will use a callable statement to access the procedures to insert or update. Some of my tables in the database have no constraints,the problem is the application behaves weird when there are more than 1000 users on the server, there are duplicate insertions in the table, this seems to be concurrency problem. How do we resolve concurrency problems in EJB, can setting specific isolation levels solve the problem.What are the various approaches for solving concurrency?
- Posted by: Gautam Rao
- Posted on: March 09 2009 02:35 EDT
The problems you experience are by no means EJB problems. Since you put all your business logic into stored procedures they are the only place where you can deal with concurrent access. In general if you plan to have a multiuser application you should design a strategy of dealing with concurrent access upfront. There are two approaches: - optimistic locking - pessimistic locking With optimistic locking you design your updates in such a way that they fail if some other thread / client does incompatible update concurrently. So whenever you do UPDATE, DELETE, INSERT you validates assumptions you made to date. One way is to use primary keys and unique indices so attempt to create "duplicate" would fail. With pessimistic locking you design your application in such a way that it won't be able to start processing unless it can acquire a lock. In Oracle it can be done using SELECT FOR UPDATE NOWAIT for some table that may work like a list of possible locks. I guess there must be something similar in MS SQL Server. P.s. why on Earth do you use stored procedures for a web site with 1000 concurrent users?! Get a book about RESTful design principles (I do not imply web services).