I've been writing similar apps (Movel 2, JDBC connection pooling,
etc) apps for a while, here's the experience that I've had:
1) If you use a vendor-supplied ConnectionPool, you don't need to worry
about synchronization. Their classes are written for multi-threaded
environments so they synchronize what they need to, and DB connections are
inherently multithreaded anyway. I've bumped into a couple of places
where I've needed to set the isolation level in my Connection object to
avoid concurrent modifications to the database, but those are rarely
needed.
2) If you use your own ConnectionPool, just make sure your code is
synchronized so that no two apps can check out the same Connection, etc.
3) Whenever possible, set attributes in the Request object and not the
Session object. You don't need to worry at all about threading issues
there, and it can't be cluttered up by other invocations of your
Model. The only thing you should set in the Session is data that needs to
persist between calls.
4) You generally don't need to worry about multithreading issues too
much in the Session, since the session is unique to an individual
user. Just use common sense here: pull Objects out of the session
just once, and use local references to them, etc. Honestly, I've only
ever needed to worry seriously about threading issues once or twice in all
the time I've been writing Servlet apps.
5) Try to avoid mucking around with the Context too much, since it's the
most susceptible to threading issues. I usually instantiate a
ConnectionPool for each context and put that in there, but that's about
it.
Hope that helps.
-- Mark Lewis
On Mon, 23 Oct 2000, Dave Smith wrote:
> Greetings,
>
> I'm just writing my first serious JSP/Servlet application and I need some advice
>about
> synchronization and concurrent threads. I'm terrified the whole thing will crash in
>production.
> What do I need to synchronize? My application looks roughly like this:
>
> Servlet/JSP ---> Model --> ConnectionPool --> DB
>
> The objects marked Model have all the JDBC code and are stored in session objects.
>
> I apologize in advance if this is covered somewhere in a FAQ. If it is please direct
>me to it.
>
> Thanks a bunch!
>
> Dave Smith
> [EMAIL PROTECTED]
>
