Hi all,
Has anyone written / worked on any kind of application checkpointing
for POE ?
Not necessarily checkpointing arbitrary POE apps, but more a framework
for developing reproducable computing, particularly in an Application
Service Provider processing ebXML / SOAP / XML-RPC / etc. The
Sessions might have to explicitly indicate when they reach a
checkpointable state, and for most simple types of request processing
this might only happen at the beginning and end of a request.
The goal would be to have an application server, for which you can
restore to the known checkpoint (ie, backup), then replay the logged
input transactions / requests, and arrive at (nearly) the same result.
Another goal is the complete record of responses; just before a
response is sent, that Session checkpoints and logs its response -
hence, the binary log of the Database becomes the application (but not
business) audit trail.
By `winding' the binary DB log to any particular transaction, you
should be able to reconstruct which Sessions were running in that
point in Database time. If you only play back a *single session*,
then assuming your database is properly multiversioning (ie, no `dirty
read', etc), and the checkpointing captures *everything* important,
you should get *exactly* the same result when stepping through with
the debugger. Hopefully it should be obvious why this might be
useful.
This sort of thing is fairly standard on Big Iron(tm), but I haven't
seen anything for it in the Mini or Micro world yet. Oh, I'm sure
that Oracle's suites, and perhaps SAP probably have something like
this.
Other applications for checkpointing are anything where you need to
`wind back' a session to a particular state following an exception.
Consider, for instance, you are using Pixie or Tangram - object
persistence layers that are generally blocking due to their on-demand
loading of data. By trapping session handlers inside eval{}, you
could work around this blocking behaviour with a DBI wrapper that
forks a Wheel::Run to fetch the data set required, then throws an
exception - and the framework replays the Session from the last
checkpoint when the data set is loaded.
This might seem at first glance to be quite inefficient (because, of
course, it is), but the idea is that you log when this happens, and
then go and alter your per-request pre-fetch profile to make sure that
the right data is loaded / locks are acquired in the first place as
soon as possible, so that the exceptions are infrequent, and the DB
gets as few discrete transactions as possible.
Anyone been down this road before with POE ?
--
Sam Vilain, [EMAIL PROTECTED]
A physicist is an atoms way of knowing about atoms.
GEORGE WALD
