Zuzzi2
asked on
How to ensure concurrency control in servlets?
Hi, may I know how to handle multiple requests to the same servlet that will update the database with the correct implementation of concurrency control?
Let's say we get the number of items in the database table. "Select count(*) from Item" returns 100.
Next we add a new Item using 100 + 1 = 101 as the item_id
Now how can I ensure that the item_id is unique, no two requests starting at the same time has added the item_id, 101 into the database?
Thanks.
Let's say we get the number of items in the database table. "Select count(*) from Item" returns 100.
Next we add a new Item using 100 + 1 = 101 as the item_id
Now how can I ensure that the item_id is unique, no two requests starting at the same time has added the item_id, 101 into the database?
Thanks.
You can also make the particular method as 'synchronized'.
synchronized public int updateCount(int value)
{
value += 1;
return value;
}
When you are doing a SELECT to get the current value, make the SELECT and the UPDATE as an atomic operation.So, the above method can have this variation:
synchronized public void updateCount()
{
//SELECT
item_id += 1;
//INSERT
}
synchronized public int updateCount(int value)
{
value += 1;
return value;
}
When you are doing a SELECT to get the current value, make the SELECT and the UPDATE as an atomic operation.So, the above method can have this variation:
synchronized public void updateCount()
{
//SELECT
item_id += 1;
//INSERT
}
You can also make the particular method as 'synchronized'.
synchronized public int updateCount(int value)
{
value += 1;
return value;
}
When you are doing a SELECT to get the current value, make the SELECT and the UPDATE as an atomic operation.So, the above method can have this variation:
synchronized public void updateCount()
{
//SELECT
item_id += 1;
//INSERT
}
synchronized public int updateCount(int value)
{
value += 1;
return value;
}
When you are doing a SELECT to get the current value, make the SELECT and the UPDATE as an atomic operation.So, the above method can have this variation:
synchronized public void updateCount()
{
//SELECT
item_id += 1;
//INSERT
}
I would agree with bazarny on using the database for concurrency control. However if this is not possible then a synchronized version much like the one that sghosh suggested would be the correct approach.
Given that, though, there is one slight problem with sghosh's approach. Since servlets are created and destroyed when connections are accepted, using synchronized in this way will not work. The synchronized keyword as used above will synchronize based on the current instance of an object, but the servlet container will have created multiple instances to support multiple connections. Each of those instances running in their own thread have a monitor which they can use to block access, but since each instance has a different monitor, you can't block access to the database from multiple instances in this way.
What is needed instead is a monitor that all instances of your servlet can share. For this, we can create a static Object in the servlet class and synchronize on that, instead. The code would look something like:
class DbUpdate
{
// This is our monitor.
static Object lock = new Object ();
.
.
.
public void incrementCounter ()
{
synchronized (lock)
{
.
.
// Do your update here...
.
.
}
}
}
HTH
--Steve
Given that, though, there is one slight problem with sghosh's approach. Since servlets are created and destroyed when connections are accepted, using synchronized in this way will not work. The synchronized keyword as used above will synchronize based on the current instance of an object, but the servlet container will have created multiple instances to support multiple connections. Each of those instances running in their own thread have a monitor which they can use to block access, but since each instance has a different monitor, you can't block access to the database from multiple instances in this way.
What is needed instead is a monitor that all instances of your servlet can share. For this, we can create a static Object in the servlet class and synchronize on that, instead. The code would look something like:
class DbUpdate
{
// This is our monitor.
static Object lock = new Object ();
.
.
.
public void incrementCounter ()
{
synchronized (lock)
{
.
.
// Do your update here...
.
.
}
}
}
HTH
--Steve
Actually that DbUpdate class is your servlet. I forgot to add the "extends HttpServlet" to the class definition.
Sorry for any confusion...
--Steve
Sorry for any confusion...
--Steve
> servlets are created
and destroyed when connections are accepted,
> multiple instances to support multiple connections
I think, this is where Servlets are distinguished from CGI.
Servlets are not created in multiple instance to handle multiple connections.
and destroyed when connections are accepted,
> multiple instances to support multiple connections
I think, this is where Servlets are distinguished from CGI.
Servlets are not created in multiple instance to handle multiple connections.
Well, from practical experience, I can safely say that at least one servlet container I've used does create individual instances. I ran into this exact problem several months ago and it turns out that this was the solution.
While from a specification standpoint, this may not be part of the spec, but there are servlet vendors out there who use multiple instances as a performance improvement, so you can't count on the fact that there will only be one servlet instance...
By using a static lock, you can safely ignore the multiple instance problem, if it exists, and this code will still work when a single instance is all that's being used...
--Steve
While from a specification standpoint, this may not be part of the spec, but there are servlet vendors out there who use multiple instances as a performance improvement, so you can't count on the fact that there will only be one servlet instance...
By using a static lock, you can safely ignore the multiple instance problem, if it exists, and this code will still work when a single instance is all that's being used...
--Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
- points to sdussinger
Please leave any comments here within the
next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !
vemul
Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
- points to sdussinger
Please leave any comments here within the
next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !
vemul
Cleanup Volunteer
per recommendation
SpideyMod
Community Support Moderator @Experts Exchange
SpideyMod
Community Support Moderator @Experts Exchange
I would use stored procedure with proper transaction control/isolation level and let db server handle concurrency issues.
Regards,
Igor Bazarny,
Brainbench MVP for Java 1
www.brainbench.com