Hi Alex,

> Usually not, though I do it in certain cases.

In what cases and how you do it?

I want to split my app into two independent processes (process
families): an admin part (quite complex, can change a lot and
significantly, can stop quite "often" for upgrades etc.) and public
part (quite simple, changes little, minimize downtime).  The reason is
that I want to be able to kill and upgrade these two parts
independently without affecting each other.

> If you have an independent process accessing such a db, it must make
> sure never to write to that db (or write only objects which are
> guaranteed not to be written by other processes), and be aware that the
> state of its cached objects might be out of date (e.g. call (rollback)
> from time to time to cause a reload).
> This is usually not so easy to guarantee, because changing a single
> object often triggers the change of many other objects as a side effect,
> like objects connected via '+Joint', or whole branches of an index tree.

I cannot guarantee that.

> In fact, there *is* an important communication going on.

Now how to achieve the above requirements?  Maybe having a master
parent process which would

- open the database 'pool'
- fork into two apps (each forked process would load code for different app)

This way I would have both apps in the same process family and could
still kill/restart them independently.

> To be on the safe side, I would recommend to allow only members of a
> single family to access a db, and implement external accesses via
> some RPC mechanisms (for queries, '*Ext' comes in handy here).

What is '*Ext', I cannot find anything about that?

> This whole matter is a good candidate for the Wiki ;-)

Yes, why not, I have to understand it first though.  Or, feel free to
put your thoughts in there;-)

Thank you,


Reply via email to