dcsimg
Restricting a method being invoked simultaneously in the Business Class
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Renjith_C
Posted On:   Monday, August 12, 2002 02:35 PM

I am having a business class which contains a method to insert a row in the oracle database, unfortunately i don't have a primary key for this table. When two clients are accessing the appllication simultaneously it is creating two rows with the same data. Please give me a optimised solution to restrict accessing the same method at the same time... what happens if i make the method both synchronised and static... ???

Re: Restricting a method being invoked simultaneously in the Business Class

Posted By:   Phil_Robare  
Posted On:   Monday, August 12, 2002 05:54 PM

The problem, as I see it, would be how to serialize access so that a "later" input identical to an "earlier" access is blocked.


First, the easy way:

If you have no primary key you could create one. Most SQL db's have a way to use the row number for a key. Then you could look up the row number using your unique key to see if something exists. If it doesn't, create the row using the unique key info and then update it. Put the check-create logic into a database procedure and run it as an atomic transaction.


Problems with the easy way:

db procedure languages are slow if you are talking a high volume application. Running them inside a transaction makes them even slower. Forcing you to update a row for every row transaction can make things slow is row creation is a common part of your application's work.


A more code intensive way:

Use JMS to communicate with a persistant process within your server. The process will receive messages from all beans that want to create or check the existance of rows. The JMS queue will provide synchronization and serialization of the messages so your process need only run a loop of read queue, check DBMS, if needed create row, open return queue, write result. The last action is either to close the queue to the caller or to cache the queue. My suggestion, if high volume is important, and a subset of your possible callers provide the majority of the calls, is to cache the JMS queue in a priority queue structure. When a calling process's queue is desired find the JMS queue reference in the priority queue, remove it, then insert it at the head of the priority queue. This way active callers are found quickly.


In my experience the more code intensive way ran 5 to 10 times faster than the way that was quicker to write.

About | Sitemap | Contact