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, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
