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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Wed Feb 19 08:49:58 EST 2014


On 2014-02-19 04:37:19 +0000, JF Mezei said:

> From multiple comments made so far:
> 
> Would it be fair to state that for a serious application 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 ?

Hilarious.  But no.  Not unless you're aiming for eventual consistency, 
and that probably wouldn't be the best approach for booking seats on 
Air Mezei or whatever your particular web-facing project is.  You'll 
usually want all of your data committed in your database.  Not split 
across some server process(es) and with some committed in the 
database(es).

Post up your application requirements, your target computing platform 
and/or preferred implementation language if that's been determined, and 
some background.  Preferably with the target transaction rates, and how 
fast you need your transactions committed — if it's a typical seat 
reservation system, then commitments are usually a few seconds at most.

If you're not interested in posting some application requirements and 
related details here — and posting that sort of information and 
database design does and probably will exceed what's typical posted 
here in comp.os.vms newsgroup — or if the requirements are as-yet 
undetermined or proprietary — then some additional reading via 
previously posted links or papers and texts or otherwise and related 
queries, or some classroom course work, or hiring some specialized 
consulting, is probably your best course.

This topic is fodder for a college course or a programming vo-tech 
course, and a look around will probably find a few similar courses 
already posted.  (I found several of these airline seat reservation 
design projects that were posted as components of training courses — 
it's a pretty obvious project for an instructor to use.)

That, or go build your project, and see what works and what doesn't, 
and what scales and what doesn't.  At the scale you're probably going 
to be working at here, you likely have room to make some scaling 
mistakes.  If you don't have excessive hardware performance for the 
scale of activity expected, then you hopefully have room to hire some 
folks to get this project and this design right, or the time to build 
up to the scale.  All this assuming you can't locate an existing 
service that provides these capabilities.




-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list