On Wed, 15 Nov 2000, Kevin Duffey wrote:
> So in code it might look something like:
>
>
> {
> SomeSession ss = new SomeSession();
> SomeBean bean = getBean(); // gets the javabean used by jsp page
>
> Date date = new Date();
> ss.setDate(date);
> bean.setDate(date);
>
> ss.doLogic();
> if(checkDate( ss.getDate(), bean.getDate()) )
> {
> bean.setResults( ss.listAllResults() )
> }
> }
>
>
> Is that good enough?
Yep, except I'd say use new Long(System.currentTimeMillis()) instead of
new Date(). You don't need any date functionality, and Date objects are
notoriously heavy to create. Longs are more efficient in every way
compared to Dates.
> You said something about a race condition. I recall
> reading about this in my threading book, but I never was quite clear on it.
> My assumption is that it would be possible for two thread/requests to
> interrupt one another, thus in the middle of one thread checking the date,
> another one could be altering it, or something like that.
>
Imagine this scenario:
Client request comes in on thread A
Servlet gets session (in thread A)
Servlet creates timestamp (thread A)
User hits stop, then does another query (assume it takes 0 time)
Client refresh request comes in on thread B
Servlet get session (in thread B)
Servlet creates timestamp, puts it in session (thread B)
Servlet puts timestamp in session (thread A)
Because of the way threading works, you're not guaranteed that they
execute in any given order. In the scenario above, if you don't
synchronise, the 'later' value might get clobbered with an incorrect
earlier one. Granted, this is VERY unlikely, and will probably happen one
in a million times, but the potential exists nevertheless.
Regarding your connection issues, I'd say look into your transactions! Two
minutes is an awfully long time. Also you should be closing them after
every transaction anyways. It doesn't really matter if the final
presentation layer gets to the client or not, when the transaction is
complete, the connection gets closed (in a finally block).
Hani
