Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is the problem inherent in a stateless application. If a user abandons the session, by just walking off or simply closing the browser, there is no good way for you to know <em>for sure</em> that the session should be closed. The best solution that I have come up with is to use a timestamp as the locking field then regularly poll for records that have been locked for "too long". Not a perfect solution but it should address 90%+ of your issues.</p> <p><em>edit after comment from OP:</em></p> <p>@ARB, Transactions are used to execute a sequence of SQL statements that may potentially need to be rolled back. It is typically reserved for save actions (inserts, updates &amp; deletes). You can not "roll back" a select statement (nothing to 'undo'). So wrapping your btnNext action (a select) and your btnSubmit action in a transaction is not needed. Additionally when I have used transactions it has been in the form of a single sequence of commands. I can't say <em>I know</em> you can't join a transaction in the middle, but I have never seen it done. Depending on the complexity of your save function following btnSubmit may be a good place to use a transaction, but then only if you are saving to multiple tables.</p> <p><em>In summary</em>: </p> <p>Because of the stateless nature of web apps, and the inability to 'force' a user to close their session 'gracefully' you need a mechanism that 'unlocks' a record that has been locked for 'too long'.</p> <p>Because there is nothing to 'roll back' in your btnNext action (a select command) there is no reason to include this in a transaction. If you wish to isolate your btnSubmit (save action) then that may be useful. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload