Hello Wayne,
Now I have the full picture.
1. HP3000 application locks a few records
2. PC ODBC application requests for a record which is already locked by
HP3000 application.
3. Since the isolation level set by PC ODBC application is RR, naturally it
has to wait for the record to be released by the 3000 application.
4. Now if the locks are monitored using SHOW LOCKS command from DBUTIL, it
displays an inappropriate message indicating a DATA SET LEVEL LOCK is going
to be put. This is due to the fact that the row level lock enhancement was
an IMAGE/SQL only solution (which was released through B.G2.07 version) and
only one item can be locked at a time in IMAGE. The PC-ODBC application may
be requesting a row lock, by specifying another item, than the one used by
HP3000 application to put the row level lock.
The scenario may be like this:
- HP3000 application uses ORDER-NUM as the item to put the lock
- PC-ODBC application uses an item other than ORDER-NUM to put the row lock
In this situation, as only one item can be specified in the lock, IMAGE
decides that another entry can't be used to put row locks, and tentatively
decides to put a set level lock. However, when HP3000 application releases
the lock, IMAGE sees that, there is no locks held on the set, and change
the tentative decision of set level lock, and goes ahead by putting a row
level lock on the new item specified.
I request you to verify this, by releasing the locks held by HP3000
application.
Also, another option is to set the isolation level to RU, in the ODBC
settings, as suggested by Joe.
Hope this helps. Please let me know of any concerns or feedback.
Regards,
Vikram
[log in to unmask] wrote:
> Further info for you. Sequence of events:-
>
> HP3000 app locks record(s) in several sets
> PC ODBC app requires data from one of the sets which has a record
> locked. It has 'Dataset' Lock waiting - not record level lock waiting!
>
> Other users of HP3000 app then want data from one of the sets where
> records are locked. App tells them database is busy.
>
> The resulting display from DBUTIL is as follows:-
>
> >>SHOW UPTIME LOCKS
> For database UPTIME
>
> PIN/ PROGRAM
> LOCKED ENTITY / ( - waiting process ) PATH NAME
> JOBNUM
> ------------------------------------------------------- -------
> -------- ------
> DATA SET ORDER-HEADER (PENDING) . . . . . . . . . . . . 548
> ODBCLNSE #J309
> -waiting for zero locks within above data set: . . . . 548
> ODBCLNSE #J309
>
> H-ORDER-HEADER: ORDER-NUMBER = 172102 . . . . . . . 538/1 MCSS
> #S534
> ORDER-DETAIL: ORDER-NUMBER = 172102 . . . . . . . . 538/1 MCSS
> #S534
> ORDER-HEADER: ORDER-NUMBER = 172102 . . . . . . . . 538/1 MCSS
> #S534
> SITE-DETAIL: SITE-NUMBER = CC389949 . . . . . . . . . . 538/1 MCSS
> #S534
>
> ORDER-HEADER is an Image Detail set. Any further clues?
> Regards,
> Wayne Laughton
>
> -----Original Message-----
> From: Wayne Laughton
> Sent: Wednesday, November 11, 1998 5:27 PM
> To: vikram
> Subject: RE: Image Locking under 5.5 PP 5
>
> Vikram,
>
> Another thought - I have just run the SQLINSTL.PUB.SYS script. Don't
> believe this had been done. Would this contribute to the problem.
>
> We also use OMNIDEX on the DB. Does this need to be a specific version
> perhaps?
> Regards,
> Wayne
>
> -----Original Message-----
> From: Wayne Laughton
> Sent: Wednesday, November 11, 1998 5:22 PM
> To: vikram
> Subject: RE: Image Locking under 5.5 PP 5
>
> Vikram,
>
> What info do you require? Not sure I understand what you mean 'an
> enhancement to support row level
> locking, with dbopen mode 1'.
>
> The info I can provide:-
>
> 16 bit ODBC Client running on WIN 3.11
> VB App on PC uses this to read and update data on 3000 (Image)
> 3000 App (3RD Party app - no source code) uses record level locking.
>
> What other info do you require?
> Regards,
> Wayne
>
> PS Thanks for the prompt response.
>
> -----Original Message-----
> From: vikram
> Sent: Wednesday, November 11, 1998 5:21 PM
> To: Wayne.Laughton; shobhap
> Cc: vikram; HP3000-L
> Subject: Re: Image Locking under 5.5 PP 5
>
> Hello,
>
> [log in to unmask] wrote:
>
> > Since upgrading from 5.0 to 5.5 Powerpatch 5 over the weekend, we have
> > seen some strange behaviour with Image locking.
> >
> > We use a 3rd party application which uses predicate locking (Item
> > level). We are also using an ODBC application to read the data out of
> > the same Image DB. This app (also a 3rd Party program) locks at set
> > level.
> >
> > Since the upgrade on the weekend, our users have been complaining of
> > being locked out of the database (the 3000 app tells users that
> > Database is busy) consistantly. Apart from the upgrade to 5.5, nothing
> > else has changed.
> >
> > Any clues as to why we would see problem with locking contention? Has
> a
> > previous bug been fixed perhaps? Any help greatly appreciated.
> > Regards,
> > Wayne Laughton
> >
> > Manager, Business Systems
> > Southcorp Water Heaters Australia
> > --------------------------------------------------
> > Southcorp Australia Pty Ltd
> > A.C.N. 004 213 665
> > Phone: + 61 2 9684 9140
> > Fax : + 61 2 9684 4270
> > Mobile: 0412 254 484
> > Inet : [log in to unmask]
> > Mail: Southcorp Water Heaters Australia
> > P.O. Box 6
> > Rydalmere NSW 2126
> > AUSTRALIA
> >
> >
> .......................................................................
> >
> > Item Subject: WINMAIL.DAT
> > Couldn't convert Microsoft Mail Message Data item to text at a
> gateway.
>
> In 5.5 PP5, there is an enhancement in IMAGE/SQL to support row level
> locking, with dbopen mode 1.
> Can we get some more details of your environment?
>
> --
> Regards,
> Vikram
> _
|
