[progress Communities] [progress Openedge Abl] Forum Post: Re: Oe 11.5 Sp1 32bit Windows,...

  • Thread starter Thread starter Simon L. Prinsloo
  • Start date Start date
Status
Not open for further replies.
S

Simon L. Prinsloo

Guest
Each connection must map the database shared memory into the client's memory space. But when the database shared memory is more than the remaining addressable space in the client, this mapping cannot be done and the connect fails. The client does not know that this is a second connection to the same db, otherwise it would tell you that it is already connected. The only way that this happen is that you give the second connection an alternative logical db name. Since the client now sees this as a "different" db, it will need to map the shared memory again. Note that when you do this, you open yourself up for other horrors, like dead-locking yourself, as the db engine will also see the two connections as two different clients. You can proof that with the following code. Connect to sports2000 with -ld SportsA. When you run start.p, it will: 1. [Start.p] Create the Alias SportsB. (You will see only one connection in promon) 2. [Start.p] Run lockMySelf,p. 2.a [lockMySelf,p] Lock the customer in one buffer. Promon will show one share lock. 2.b [lockMySelf,p] Run the internal procedure. 2.c [lockMySelf,p] Read the same customer in another buffer. Promon still shows only 1 lock. 2.d [lockMySelf,p] Upgrade the lock and update the record. 2.e [lockMySelf,p] The main block display the updated value using the first buffer. 3. [Start.p] Delete the Alias SportsB. 4. [Start.p] Connect to sports2000 with -ld SportsB (You will now see two connections in promon) 5. [Start.p] Run lockMySelf,p. 6.a [lockMySelf,p] Lock the customer in one buffer. Promon will show one share lock from the first connection. 6.b [lockMySelf,p] Run the internal procedure. 6.c [lockMySelf,p] Read the same customer in another buffer. Promon shows 2 share locks on the same record, one from each connection. 6.d [lockMySelf,p] Upgrade the lock and update the record. Promon shows that the second connections queue for an exclusive lock. At this stage the session locks itself up indefinitely. /* lockMySelf.p */ FIND FIRST SportsA.customer. /* Take a share lock */ RUN UpdateCust. DISP SportsA.customer.name. PROCEDURE UpdateCust: FIND FIRST SportsB.Customer. ASSIGN SportsB.Customer.Name = SportsB.Customer.Name + " Test". END PROCEDURE. /* Start.p */ CREATE ALIAS SportsB FOR DATABASE SportsA. RUN lockMySelf.p. DELETE ALIAS SportsB. CONNECT -db Sports2000 -ld SportsB. RUN lockMySelf.p.

Continue reading...
 
Status
Not open for further replies.
Back
Top