Thanks Mark, much appreciated,
I will implement what you suggest, certainly seems like the best solution.
In my case the update is a simple one (only one integer and one small String
field) so from what you're saying I should be fine performance-wise.
I spose for high scalability on an app with big updates the answer would be
to use a DB which supports row-level locking.
Damn I love this stuff. Its just so.........interesting : )
Paul
> -----Original Message-----
> From: Mark Galbreath [mailto:[EMAIL PROTECTED]]
> Sent: 18 July 2001 01:34
> To: [EMAIL PROTECTED]
> Subject: Re: concurrent access to variables with class or block scope
>
>
> I think servlet database access synchronization issues is a
> perfect subject
> for this list.
>
> I think you are going to run into update contention with
> storing access
> class instances as local variables; I think synchronizing on
> a static update
> variable will not cause you appreciable performance problems
> unless you are
> running a massive query. Remember to release the lock with notify and
> release the connection in your catch (or preferably, your
> finally) clause.
>
> Cheers!
> Mark
>
> ----- Original Message -----
> From: "Paul Foxton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 17, 2001 6:33 AM
> Subject: Re: concurrent access to variables with class or block scope
>
>
> > 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
> >
>
> ______________________________________________________________
> _____________
> 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
