Dear Members and ann W. Harrison,

From your reply I think that I need to run lock manager with proper
privileges ,

>On some Unix variants, processes can signal only within
> their process groups, which works very badly if a database is
> shared by process that don't share groups. In that case, a process
> variously called gds_lock_manager and gds_relay runs with setmod
> privilege to relay signals.

My understanding of embed is both server and client is of single
process. DB When I make multiple connection in my embedded
application. It will be handled in single process (that is with my
application process)? Even in my observation when I made multiple
connection no other separate "fb" process has spawn in my machine for
each connection.

If separate process gets spawn then only lock manager need to be
spawn. So kindly tell me what is behaviour in linux embedded?

If classic server architecture is not capable of handling multi
threading in embedded , I think we can build separate embedded build
for linux based on Super server architecture similar to windows.

I am worng kindly correct me,

Thanks & Regards,
S.Karthick

--- In Firebird-Architect@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

>
> >
> >My application has embedded firebird db. When I connect db through
> >classic libraries in linux , I get a messages that "lock manager:
> >couldn't set uid to superuser". I get this messages when i make
> >multiple connection in my firebird embedded application. I get this
> >message only in linux,
>
> The embedded firebird for linux is actually the old 'classic'
> architecture and quite different, structurally, from the embedded
> version on windows. Windows uses a multi-threaded server library
> which opens the database file exclusively then handles all connections
> coming from the application and allows them to share a page cache
> and a metadata cache.
>
> The classic architecture has a single threaded library of database
> services - implemented as a shared object library. Each connection
> gets its own page and metadata cache. The classic architecture uses
> a shared memory area called the lock table to coordinate access.
> When the lock management code discovers that one process needs a
> resource that another process has locked, it signals the other
> process. On some Unix variants, processes can signal only within
> their process groups, which works very badly if a database is
> shared by process that don't share groups. In that case, a process
> variously called gds_lock_manager and gds_relay runs with setmod
> privilege to relay signals.
>
> That process must be installed and run with the correct privileges.
>
> Regards,
>
>
> Ann