bni@modulex.dk (Bent Nielsen) (02/13/90)
Someone has explained to me how Ingres lock is working, but I don't understand it, please help. 1) Is it correct that if I have a record length of 128 bytes and uses SELECT .... FOR UPDATE on one record then 4 records, one whole page (512 bytes on UNIX), will be locked? 2) I am familiar with Oracle SQL*Forms and Forms is using SELECT .... FOR UPDATE, when a user start to change a retrieved record and only this record will be locked. How can I implement this in Ingres if 1) is correct? -- Bent Nielsen <bni@modulex.dk> A/S MODULEX Lyskaer 15 DK-2730 Herlev Denmark
ron@augeas.AthabascaU.CA (Ron Haukenfrers) (02/19/90)
bni@modulex.dk (Bent Nielsen) writes: >Someone has explained to me how Ingres lock is working, but I >don't understand it, please help. >1) Is it correct that if I have a record length of 128 bytes > and uses SELECT .... FOR UPDATE on one record then 4 records, > one whole page (512 bytes on UNIX), will be locked? >2) I am familiar with Oracle SQL*Forms and Forms is using > SELECT .... FOR UPDATE, when a user start to change a > retrieved record and only this record will be locked. > How can I implement this in Ingres if 1) is correct? >-- >Bent Nielsen <bni@modulex.dk> >A/S MODULEX >Lyskaer 15 >DK-2730 Herlev >Denmark Ingres has the concept of a page (2k). When it performs a lock, it locks the whole page. Because your record size is less then the page size, ingres is placing mutiple records in each page. This 2k page is also why you can not create a record larger than 2k in Ingres. If this method of locking is a problem, the only sugestion I have is to set the fill factor for that table to one record per page. (modify command) This increases the overall size of your database, but it will enable you to lock only one record at a time. Hope that helps. -- Ron Haukenfrers {alberta,cbmvax,decwrl}!atha!ron Educational Computing or ron@cs.AthabascaU.CA Athabasca University
dmn@stiatl.UUCP (Michael Nowacki) (02/21/90)
In article <1671@aurora.AthabascaU.CA> ron@augeas.AthabascaU.CA (Ron Haukenfrers) writes: >bni@modulex.dk (Bent Nielsen) writes: > > >>1) Is it correct that if I have a record length of 128 bytes >> and uses SELECT .... FOR UPDATE on one record then 4 records, >> one whole page (512 bytes on UNIX), will be locked? > >>2) I am familiar with Oracle SQL*Forms and Forms is using >> SELECT .... FOR UPDATE, when a user start to change a >> retrieved record and only this record will be locked. >> How can I implement this in Ingres if 1) is correct? > >Ingres has the concept of a page (2k). When it performs a lock, it locks >the whole page. i am interested in this issue, too. note that the lock request made by the user is, naturally, in terms of data. locking is provided in terms of disk space. at a recent ingres training class, i was told that when defining the original locking mechanism for ingres, a poll of then-current users was taken and few wanted to spend the system resources necessary for record level locking, so they implemented page-at-a-time locking. clearly, this is unacceptable for on-line applications with many users. i am planning to create an SIR about this, proposing the option of record level locking be implemented in ingres. note that this is not as large a request as it would have been in v5, because as of v6, all ports of ingres use ingres' implementaion of a lock manager; vms does not use vms's anymore. i mention it here because Ingres Corp (tm) does not appear to be pro-active in addressing this, so if users want it, they will have to ask for it. so, next time you're on the phone to customer support... -- Michael Nowacki gatech!stiatl!dmn Sales Technologies, Inc |\ /| 3399 Peachtree Rd, NE | \/ | Atlanta, GA (404) 841-4000 _|ike |_
jkrueger@dgis.dtic.dla.mil (Jon) (02/21/90)
dmn@stiatl.UUCP (Michael Nowacki) writes: >i am planning to create an SIR about this, proposing the option of record level >locking be implemented in ingres. Not clear this is a good thing; as you point out, one trades finer granulariy of locking for throughput and possibly latency. Concurrency performance in general is quite hairy. Consider other vendors' options here and how configurable they are or are not. It's a mixed bag. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.