Samofatov, Nickolay wrote:

>>If we can flush the difference between classic and superserver,
>>everyone's life gets a great deal simpler.
>>
>>
>>
>2. There are cases when spawning lots of child processes may be
>offending behavior. In embedded case this is bad on UNIX platforms too
>so killing SS is not an option.
>
>
>

Sorry, I guess I wasn't clear.

I am not suggesting that we kill the superserver architecture, per se,
but we merge classic and superserver into a single unified engine. The
behavior of the entire would be controlled by (hopefully) a single
configuration parameter of, maybe, two states:

1. The database file is to be opened shared. In this case locks are
expressed in the lock manager with blocking ASTs as per classic.
In fact, it is classic.
2. The database file is to be opened exclusively but multiple
attachments are supported. Locks are not exported. This
corresponds to superserver.

The engine would always interlocked for multiple threads.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376