> 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;-)
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]