• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 279
  • Last Modified:

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.
0
Zuzzi2
Asked:
Zuzzi2
1 Solution
 
Igor BazarnyCommented:
Hi,

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
0
 
sghosh092199Commented:
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
}
0
 
sghosh092199Commented:
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
}
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
sdussingerCommented:
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
0
 
sdussingerCommented:
Actually that DbUpdate class is your servlet. I forgot to add the "extends HttpServlet" to the class definition.

Sorry for any confusion...

--Steve
0
 
sghosh092199Commented:
> 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.

0
 
sdussingerCommented:
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
0
 
sdussingerCommented:
After a little more research, I discovered that the servlet specification prior to 2.2 did not specify how multiple instances would be handled. That was left up to the container implementer to decide. In the 2.2 specification, it was tightened to specify that if a Servlet did not implement SingleThreadModel it would only be created once. Any Servlet which does implement SingleThreadModel will be created for each invocation of the servlet.

So servlet containers prior to the 2.2 spec are free to create as many instances as they like, to handle the incoming requests. Servlet containers which are 2.2 compliant should not create multiple instances, unless specifically requested by implementing the SingleThreadModel interface...

--Stevce

0
 
vemulCommented:
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
0
 
SpideyModCommented:
per recommendation

SpideyMod
Community Support Moderator @Experts Exchange
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now