Re: Maximum number of group and other locks allowed on D3?

When operating within a BEGIN TRANSACTION - COMMIT TRANSACTION the process
creates group locks.  The lock table was taking lots of 43 line pages just
to list.  So does the lock table sort of have a modulo of 1, and so clearing
the lock table allowed the process to complete in quick time because the
system didn't have to traverse such a huge lock table?

I know when the commit happened on a transaction size of about 900, that is
when the beeping started, and the port committing the transaction was the
only major process working on the system.  The other process that may have
been trying to lock anything would have been the background processor trying
to lock the BACKGROUNDS file and other background related files.

I know that these big transactions are a whole lot too huge to be even
considered reasonable, but I only inherited the system and I get to work
with it.

I'm trying to limit the amount of damage that can happen should a crash
happen in the middle of one of the huge updates.  I suppose one way to
handle these huge updates is to schedule them to run as the only process on
the system, and right after a full backup.  If the system somehow stops in
the middle of everything, I can do a restore from the backup.



"Mark Brown" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> If you are NOT using D3's locking scheme, and you didn't get any beeping,
> what make you think you had a locking problem?  the fact that someone did
a
> clear-locks (and we don't even know which version [group, item, update,
> system]) may just be coincidental.
>
> The transaction logger has it's own "lock", a two-byte non-zero field to
> tell the world not to screw with the queue for a while, but that only
lasts
> as long as it takes to move the data into the queue, update the
end-of-queue
> pointer and release the lock.
>
> However, if you have 2500 transactions in the queue, it's a little like a
> file with a modulo of 1.  Every update is going to take longer and longer.

> And every time you want to re-read one of those updated records, it has to
> look first in the queue and then in the file.  You could be spending all
> your time traversing the queue.  If these are large records, you could
> have>2K frame faults PER READ/WRITE.
>
> You might want to consider what it is you are protecting yourself from.
If
> the first record cannot be written into the file until the 2500th record
is
> also written, there's too much interdependence.
>
>
> "Dale Benedict" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Insights, etc imbedded.
> >
> > Regards,
> >
> > Dale
> >
> > "Mark Brown" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > There is no theoretical limit, though time and gravity will always
exert
> > > certain physical limitations.  The time it takes to traverse the lock
> > table
> > > gets longer and longer with each new item.  And the more frames in the
> > > table, the more likely you are to frame fault and lose your timeslice.
> > >
> > > My question is: why are all those records locked?  You only need to
hold
> > the
> > > lock until the item is written.  Once it goes into the transaction
> stream,
> > > it no longer needs to be locked.
> >
> > The transaction process itself creates the group lock.  I expect to
> prevent
> > the group from shuffling during the transaction.
> > >
> > > Your locks never hinder YOU, only other processes attempting to
> read/lock
> > > the same item.  Unless that other port cleared-locks with the U option
> to
> > > clear all locks for everyone, someone else was holding an item locked
> and
> > > you ran into it.  That's a common hazard of attempting to update the
> world
> > > with a single shot.
> >
> > As for someone else holding a lock that was not happening here!  The
> program
> > wasn't giving any beeps to indicate that a group was locked.  And as for
> our
> > programs we don't use Pick's native record locking to lock items.  We
have
> a
> > home grown solution to record locking that was conceived in the R82/83
> days
> > to give a more ganualar locking scheme.
> >
> > And as for Tony's insight, I hope to get some answers from my VAR.
> >
> > >
> > > Mark Brown
> > >
> > >
> > > "Tony Gravagno" <[EMAIL PROTECTED]> wrote in
message
> > > news:[EMAIL PROTECTED]
> > > > Unless Mark knows off-hand, this sounds like a good question for the
> > > > RD Forum which is monitored by Engineering and Support staff.
> > > >
> > > > Tony
> > > >
> > > > "Dale Benedict" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >What is the maximum number of group locks and item locks allowed on
a
> > D3
> > > 7.3
> > > > >or 7.4 Linux system?  Does anyone know?
> > > > >
> > > > >I'm trying to implement transaction bracketing here.  The old code
> here
> > > will
> > > > >on occasion update thousands of records in one transaction.  I'd
like
> > to
> > > get
> > > > >the bracketing working so that if there is some sort of crash in
the
> > > middle
> > > > >of the huge transactions, the investigation and cleanup of the data
> > > doesn't
> > > > >take a whack o' time.
> > > > >
> > > > >I had one transaction reaching close to 2500 according the command
> > > > >TRANSACTION STATUS (G command, and the process seemed to stall
doing
> > > > >something with locks.  A 'clear-locks' on another line allowed the
> > > > >transactioned process to complete.  Did I max out the lock table?
> > > > >
> > > > >Thanks for your attention!  Regards,
> > > > >
> > > > >Dale
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>