Understanding Java app server class persistence in web apps
<p>Am I correct in my understanding of web app client/server persistence?
I'm ready to be SDIF (shot down in flames) which would be great. i want to learn
apologies if this is somewhat general but it will lead to more specific questions once I understand i'm sure</p>

<p>This is what I've come up with after numerous hours of googling and writing a demo web app...
(I'm sure it's basic stuff but getting to the root of how it all works isn't easy)</p>

<ol>
<li><p>A web client can't ever maintain a persistent connection for the duration they have a web page loaded, because HTTP simply sends and receives requests?</p></li>
<li><p>On the server side when a class (i.e. servlet) is invoked it is created and destroyed when finished it's work. Even with an AJAX call this is true. A servlet is transient</p></li>
<li><p>There can be no instance of a class that stays loaded in between HTTP requests from the same user?</p></li>
<li><p>But can the frameworks simulate this?</p></li>
<li><p>It seems they do this by persisting to XML on fileserver or databases rather than Java classes, This means things like db connections can't be persisted only pooled? (I know persisting open db connections is bad, but can it be done? See scenario below)</p></li>
<li><p>You want to persist some record locking data. If it was stored on app server in objects you are limited to one application server when you may want this to be shared over multiple servers, that's why they go to XML or the db?</p></li>
</ol>

<p>A scenario:
User opens a page to edit and pesimistic row record lock is held, user takes an hour then saves, changes committed, connection closed, lock freed
Second user on same record will get db timeout set for 10 seconds and screen opened read only</p>

<p>Now that isn't so easy to do in web app, right because connections can't be held open?</p>

<p>One alternative is optimistic locking instead - this means second user can open screen, make changes but save will fail with warning data is changed</p>

<p>I don't like that, what if second user did an hours work only to find they can't save? Merging isn't an option, they lose their work</p>

<p>How about this:
Users opens a screen. A 'record lock' record written to db table storing locks with a timestamp
Every 5 minutes Javascript sends 'still here' to servlet which updates the timestamp
Second user tries to edit, check the lock table and told record is locked
Setup a db job every 10 minutes to delete lock records older than 5 minutes
If first user closes browser, this eventually will free the lock</p>

<p>The 'still here' request may or may not be very scalable. In practise... I don't think it would be much of a hit on resources</p>

<p>Thanks for any comments. I'm just transitioning into web programming from standalone apps. </p>
