Thanks Mark,
this brings up an interesting point I think
(assuming the database does not handle concurrency - I _am_ using MySQL and
tomcat so no EJB):
If the servlet was accessing a class used to handle database connections,
there would be
2 possibilities to handle the concurrency issue:
1. Instantiate the class in a local variable in a method in the servlet.
This would mean a new instance of the class for every request to the
database.
Some kind of row locking for the update would then still need to be used
to handle concurrent access to the same row in the databse.
As far as I can gather from the MySQL manual only table-level locking is
supported.
2. Store the class in an instance variable in the servlet.
The methods used to connect to the database would then need to be
synchrionized.
Presumably solution 1 would mean a greater load on the server resources,
while solution 2
would mean queueing requests to the class, perhaps with the possibility of
deadlock, or at the least
meaning that users may potentially have to wait longer for their request to
be processed.
Both could create problems on a high traffic site, am I right?
In this case which would be the better solution?
just let me know if I'm getting too far off topic with this :)
thanks,
Paul
> -----Original Message-----
> From: Mark Galbreath [mailto:[EMAIL PROTECTED]]
> Sent: 16 July 2001 23:36
> To: [EMAIL PROTECTED]
> Subject: Re: concurrent access to variables with class or block scope
>
>
> In a servlet world, the database handles concurrency (at
> least, any database
> that supports transactions - mySQL does not). If the
> database does not
> support transactions, you must either synchronize the database calling
> methods or the instance variables holding the update values.
> If you use
> entity CMP EJBs, the EJB container will take care of
> transactions for you,
> or if you use BMP EJBs (either entity or stateful session),
> the database
> must handle transactions.
>
> Cheers!
> Mark
>
> ----- Original Message -----
> From: "Paul Foxton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 16, 2001 10:21 AM
> Subject: concurrent access to variables with class or block scope
>
>
> > Hi all,
> >
> > I've been wondering about the fact that concurrent requests
> to a servlet
> > will result in a new thread being created to access the
> same instance of
> the
> > servlet as long as singleThreadModel is not implemented
> with reference to
> > the following:
> >
> > If you have a servlet which accesses a database, and
> request parameters
> from
> > an HTML form are used to build the SQL where clause, if
> these request
> > parameters are stored in class instance variables (i.e.
> declared at the
> > beginning of the class and outside of any methods, so class
> scope), would
> > this mean that there is a possibility of data being
> overwritten in the
> > middle of 2 or more concurrent requests and therefore
> compromising the
> > integrity of the data retrieved from the database?
> >
> > If so, I would have thought that the way around this is to store the
> values
> > from the request parameters in variables declared inside
> methods, which
> > would then have block scope within that method.
> >
> > But surely, if two requests (threads) run through this
> block at the same
> > time there is still a possibility of a problem with data integrity?
> >
> > This doesn't seem quite right to me tho, because then you
> would have to
> > synchronize access to any method or variable which was used
> to build an
> sql
> > query or update.
> >
> > Can anyone clarify?
> >
> > Sorry if this is an obvious question. I've read through the
> documentation
> on
> > threads in servlets at Suns java site, but am still a
> little confused.
> >
> > Thanks,
> >
> > Paul
> >
> >
> ______________________________________________________________
> _____________
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives:
> http://archives.java.sun.com/archives/servlet-interest.html
> > Resources:
> http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
>
> ______________________________________________________________
> _____________
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
> http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
