[Info-vax] OT: Record locking for web transactions

[Jan-Erik Soderholm]

JF Mezei wrote 2014-02-19 05:37:
>  From multiple comments made so far:
>
> Would it be fair to state that for a serious application...

Again, "serious" is not a very well defined thing. :-)
Things very much "depends".

> you would want
> to have a server process that is contsntly running and mindful of state
> of transactions, which allows for REST transactions from detacted web
> clients ?

You would probably want to keep the status in the database,
having it only live in memory or in some process environment
gives problems at system restarts.

> (as opposed to each web client triggering their own PHP script that
> accesses the database when they press SUBMIT).
>

That is a completely different matter. You can have persistent
processes that executes the "submits", that has little
to do with the transaction modell as such.

For high volume work you usualy do not want each client access to
startup a separate server process. At least not on VMS... :-)

Now, this persistens process can still start and run a specific
PHP (or Python in my case) script at each submit, it just runs
much faster.

And again, it very much depends on the actual application.
Let's say some production control system where you have web
clients displaying actual status of lines and machines.
In that case it might be reasonable to have a server process
that keeps the total status in-memory that the web clients
access (probably some Ajax like interface) to fetch the
actual status. System restarts is not a problem since the
server process can reread/rebuild the status at startup.

So, it is hard to give a single answer for every case, it
very much depends on the actual application at hand and there
are meny different solutions and interfaces available.

Jan-Erik.