Hi Tomas,
> that all picolisp processes spread over many machines managing many
> databases all communicating (interconnected, in what sence?) to solve
> one (or many "unrelated") business problem? I looked at SmApper
> website and it seems quite a secret technology;-)
Well, then I cannot tell too much ;-) These are not mercantilistic but
technical applications. Large companies have filer systems with many
volumes, totaling several hundred terabytes of data. A sophisticated
piece of SmApper software (in C++) operates on these filers and extracts
or manipulates miscellaneous information. These data are fed into a
chain of PicoLisp databases, one chain for each mounted volume. A chain
currently consists of three elements, communicating with each other back
and forth, and the final element provides a total view common for all
volumes. The C++ part operates on the filer data, depending on the
dressed-up information and a rules engine in the common database, which
in turn queries the preceding chain elements. The mentioned admin part
is separate from this. It starts, stops and monitors these processes.
> (app 1 server and admin 1 server share the same database: read-write)
> ... etc for other applications
What I'd like to know first: Is it necessary here that they both share a
common database, or would it also be conceivable that each has its own
database, and they just exchange information?
These are two different concepts, but the second one has some advantages
if the amount of shared data is not too big.
If you go with a common database, I would do it like this: The parent
process only loads "lib/http.l" and a common "er.l", defines a function
'admin'
(de admin ()
(load "admin/main.l")
(startAdmin) )
and then starts (server <port> "lightweight/main.l").
If a user connects to <port>, he will see the lightweight application.
A user that wants to call the admin application, connects to
http[s]://server/@admin
Basically, this is how I do it in that app with different GUIs. You
still have a single parent process but different programs.
> What do you mean by "processes accessing db are children of single
> parent"? Does it mean just the one above or any common parent up high
> the hierarchy tree?
Just one above. The limitation is caused by 'tell', which is called by
'commit' internally.
(tell 'sym ['any ..]) -> any
Family IPC: Send an executable list (sym any ..) to all family
members (i.e. all children of the current process, and all other
children of the parent process, see fork) for automatic execution.
So 'tell' relays changes only to its sister processes (and to its own
children, but this has not shown to be of much practical value).
Therefore, it is best if all processes that want to modify the database
are of the same generation, with a common ancestor.
> As the http server forks new child process for each request, does not
> it mean that for each request I would have to load whole app 1 code
> depending whether the request is for "app 1 server" or "admin 1
> server" if the parent must be just the one above?
I would expect the server to fork a new child process only upon the
first connect. Then the app code is loaded, and a session is started.
After that, the 'load' on each request is minimal (or zero if you use
"@function").
BTW, the same thing applies to the database caching, not only the
'load'ing of sources.
> If I understand it well, then the db stays consistent and properly
> synchronized no matter which process calls pool as long as the
> processes have the same direct parent process.
Yes, and as long as these processes behave well, i.e. only change
objects between (dbSync) and (commit 'upd), or call the wrapper methods
'put!>', 'inc!>', 'del!>' etc.
> Sorry, I am missing something, where can I find this 'ext' function
> and '*Ext' global?
They exist since picoLisp-2.3.3. Is there no "doc/refE.html#*Ext"?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
