# Web DBI - State-less-ness

- ## No fixed client-server pair

  - Each request can be handled by a different process.
  - So can't simply stop fetching rows from $sth when one page is complete and continue fetching from the same $sth when the next page is requested.
  - And transactions can't span requests.
  - Even if they could you'd have problems with database locks being held etc.

- ## Need access to 'accumulated state' somehow:

  - via the client (e.g., hidden form fields - simple but insecure)
    - Can be made safer using encryption or extra field with checksum (e.g. MD5 hash)
  - via the server:
    - requires a session id (via cookie or url)
    - in the database (records in a session_state table keyed the session id)
    - in the web server file system (DBM files etc) if shared across servers
    - Need to purge old state info if stored on server, so timestamp it
    - See Apache::Session module
  - DBI::ProxyServer + connect_cached with session id may suit, one day

## .

Previous slide | Next slide | Back to first slide | View graphic version