Subject Re: [IB-Architect] Synchronisation between classic architecture server processes
Author Jan Mikkelsen
Ann,

Thanks for the reply.

The reason for these particular questions is that it struck me that a
classic server could be turned into a linkable library. This would remove
the need for single user applications to start a separate process, and also
avoids disrupting other IB applications on the system.

I don't suppose this has been considered, and the code is nicely #ifdef'd
out somewhere?

Multiuser applications on multiple machines would require a locking
infrastructure which isn't there, and in any case, in that kind of
environment a designated server process (or machine) isn't a problem.

Regards,

Jan.


-----Original Message-----
From: Ann Harrison <harrison@...>
To: IB-Architect@onelist.com <IB-Architect@onelist.com>;
IB-Architect@onelist.com <IB-Architect@onelist.com>
Date: Friday, 24 March 2000 10:32
Subject: Re: [IB-Architect] Synchronisation between classic architecture
server processes


>From: Ann Harrison <harrison@...>
>
>At 09:15 AM 3/24/00 +1100, Jan Mikkelsen wrote:
>
>>Presumably any server process connects to the shared memory and acquires
and
>>releases locks. Given that a server process can die at any time for any
>>reason, how are locks for dead processes released?
>>
>>Off the top of my head, I can imagine a scheme where each server process
>>records its process ID in the shared locking structure. If another server
>>process gets contention on a particular lock, it checks to see whether the
>>process is alive, and if not can clean up. Is that what happens?
>
>More or less. When there's a block, the blockee signals the blocker.
>If there's no answer, after careful consideration, the blockee declares
>the blocker dead.
>
>
>>I guess the server processes just communicate using a TCP circuit, and the
>>locking process is responsible for releasing the locks of processes that
>>die.
>
>No, I don't think it's a TCP circuit... but I really don't remember how
>it works.
>
>
>>On lock types:
>>
>>You've mentioned page locks, table locks and transaction locks.
Presumably
>>transaction locks are used for distinguishing between a dead and an in
>>progress transaction.
>>
>>Other than these, what locks are there?
>
>enum lck_t {
> LCK_database = 1, /* Root of lock tree */
> LCK_relation, /* Individual relation lock */
> LCK_bdb, /* Individual buffer block */
> LCK_tra, /* Individual transaction lock */
> LCK_rel_exist, /* Relation existence lock */
> LCK_idx_exist, /* Index existence lock */
> LCK_attachment, /* Attachment lock */
> LCK_shadow, /* Lock to synchronize addition of shadows */
> LCK_sweep, /* Sweep lock for single sweeper */
> LCK_file_extend, /* Lock to synchronize file extension */
> LCK_retaining, /* Youngest commit retaining transaction */
> LCK_expression, /* Expression index caching mechanism */
> LCK_record_locking, /* Lock on existence of record locking for this
>database */
> LCK_record, /* Record Lock */
> LCK_prc_exist, /* Relation existence lock */
> LCK_range_relation, /* Relation refresh range lock */
> LCK_update_shadow /* shadow update sync lock*/
>};
>
>
>>Are the only locking modes shared and exclusive?
>
>static CONST UCHAR compatibility[] = {
>
>/* Shared Prot Shared Prot
> none null Read Read Write Write Exclusive
*/
>
>/* none */ 1, 1, 1, 1, 1, 1, 1,
>/* null */ 1, 1, 1, 1, 1, 1, 1,
>/* SR */ 1, 1, 1, 1, 1, 1, 0,
>/* PR */ 1, 1, 1, 1, 0, 0, 0,
>/* SW */ 1, 1, 1, 0, 1, 0, 0,
>/* PW */ 1, 1, 1, 0, 0, 0, 0,
>/* EX */ 1, 1, 0, 0, 0, 0, 0 };
>
>
>>When can we get the source code, so we don't have to ask so many
questions?
>>:-)
>
>You are an inspiration.
>
>Ann
>
>------------------------------------------------------------------------
>Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
>Get automatic protection and access to your important computer files.
>Install today:
>http://click.egroups.com/1/2344/3/_/_/_/953854356/
>------------------------------------------------------------------------
>
>To unsubscribe from this group, send an email to:
>IB-Architect-unsubscribe@onelist.com
>
>
>
>