SRV.2.2 Number of Instances
The servlet declaration which is part of the deployment descriptor of the Web application
containing the servlet, as described in Chapter SRV.13, “Deployment
Descriptor”, controls how the servlet container provides instances of the servlet.
For a servlet not hosted in a distributed environment (the default), the servlet
container must use only one instance per servlet declaration. However, for a servlet
implementing the SingleThreadModel interface, the servlet container may
instantiate multiple instances to handle a heavy request load and serialize requests
to a particular instance.
In the case where a servlet was deployed as part of an application marked in
the deployment descriptor as distributable, a container may have only one instance
per servlet declaration per Java Virtual Machine (JVMTM). However, if the servlet
in a distributable application implements the SingleThreadModel interface, the
container may instantiate multiple instances of that servlet in each JVM of the
Are they saying the default is a servlet not hosted in a distributed environment or the other way around? And how is the term instance defined here? I can't understand from the documentation whether there is more than 1 object of a servlet alive at once.
I read that as "One instance per JVM unless SingleThreadModel, in which case maybe more than one instance per JVM". Is your requirement to synchronize this method across instances in more than one JVM?
Rob Micah wrote:In the past I have read here on this forum that keeping more than 1 instance per servlet was not a requirement for a J2EE container so that's why I've been digging into the spec to see if I can figure this out.
Yeah, it's possible that I may have been one of those who posted that information here in the past. (That there may be more than one instance of a servlet, that is.) It appears to be incorrect for Servlet 2.4, based on what you posted. Although I vaguely remember people posting that if there were several servlet mappings which referred to the same servlet, then the container could create an instance of the servlet for each servlet mapping. (This also may be incorrect as your quote from the spec doesn't mention or refer to that in any way.)
But anyway if you have to synchronize, I don't see that it makes much difference whether there's only one instance or not. Sure, if you're guaranteed there's only one instance you can synchronize on that instance, but if you aren't guaranteed that then you can synchronize on the servlet's class instead. And if you're uncertain about the number of instances you could plan for the worst and assume there might be more than one. There really isn't any significant difference between the two choices anyway.
James Boswell wrote:Rob
What do you mean by duplicate?
This is difficult to explain without getting very deep into the logic of the entire web application. So I'm just going to try and describe it simply.
This particular servlet receives a request from the client and uses the information from that request to update several tables on a database. Sometimes that request from the client gets duplicated and I receive more than one request containing the same information. As long as the logic that does the update is synchronized this is not a problem. But right now it's not and so I'm looking for a way to do this.
Does that make sense?
Paul Clapham wrote:
Rob Micah wrote:The other problem I have is that this stored procedure I am calling from my EJB has a commit statement right in the middle of it.
Yup, that sounds like the culprit all right.
I really hope you are right but something's bothering me about this. If EJBs are thread-safe, shouldn't this method complete all the inserts/updates regardless of the extra commit before another execution of this EJB is allowed?
Would it not be better for an additional piece of logic to check for and prevent duplicates?
I don't really see how using synchronized is going to help you here. Say you have 2 users, each with same request, trying to insert data into DB. Using synchronized is only going to prevent the inserts occurring together as opposed to one after the other. The end result will still be the same though - 2 duplicate records in DB.
Paul Clapham wrote:Yes, that can easily happen if the duplicate-detection isn't part of the transaction which updates the database.
Rob Micah wrote:I do have a method for checking duplicate data. The problem is it's running concurrently and so a race condition occurs.
Paul, can you go into more detail here? When you say the duplicate detection isn't part of the transaction, do you mean part of the JDBC transaction?