[AccessD] Connections and Performance

Jim Dettman jimdettman at verizon.net
Fri Feb 2 12:11:45 CST 2007


John,

  Locks are never written to disk.  They only exist in the OS/NOS where the
file resides.

<<It isn't apparent why an LDB file is even required. >>

  Basically, the .LDB file is a place holder for the placing of locks.
Yes, it does physically store the user name and machine name and it will
never grow physically bigger then 16K, but that info could have been easily
placed in the MDB file in the database header page.

  It's real purpose is to simply exist allowing JET to place locks on it.
The locks placed are place on byte ranges that extended beyond the physical
limits of the file.  Ie. The file will never be bigger then 16K, but nothing
stops me from taking a lock out on byte 1,000,000,000.

  By placing locks on the LDB file and not the MDB, there is never any
interference from another process when a process wants to read/write to the
database file.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Friday, February 02, 2007 12:56 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Connections and Performance

>Actual record locks on the database are stored in the .ldb too, but in a
very odd way.  When I first read about it, I thought it was the oddest
thing.  Basically, the max size of an .ldb is going to be 16k.  (255*64).
However, there is a 'virtual' size of the .ldb.  If Jet needs to lock
something in the 25th megabyte of an .mdb, it creates a lock on that
position in the 'virtual .ldb', even though the .ldb isn't that big, file
read/write code can lock bits outside a file's actual space.  This prevents
any read/write locks on the actual .mdb.

Well you lost me down around the "virtual" part.  If the "virtual" part is
in the LDB file then it has to be inside of the physical LDB file.  The OS
will not allow writes to physical disk space that is not assigned to that
file.  If it did allow that then you would get the possibility of
overwriting data in areas of the disk that the file doesn't own.  The FAT
system (and the others as well) specifically assigns sectors to files using
a chaining mechanism.  While it is possible to work around that fat system
using low level calls to the bios, I doubt seriously that Access is doing
that.

Are you saying that it grows and shrinks the LDB file, placing data out past
the first 16 KB, and that area holds the lock info??  I always just assumed
that the lock file said "this user is ACTIVELY accessing the MDB RIGHT NOW",
and the actual locking info was stored inside of the MDB somewhere.  It
isn't apparent why an LDB file is even required.  The info stored in the LDB
could just as easily be stored inside the MDB as well.  The only reason I
can see is to allow external applications to see who is in the database
without having to poke around in the MDB file itself.

Your explanation was uhhh... Virtual I suppose.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Friday, February 02, 2007 12:32 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Connections and Performance

The Jet LDB white paper explains it.

Essentially the .ldb is going to be 64 bytes per user.  Each chunk is 32
bytes for the machine name, 32 bytes for the Access User name.  Then there
is a chunk of bytes in the .mdb itself, 2 or 4(not sure about Jet 4.0, I
haven't seen a white paper on it) byte chunks, and there are 255 of them.
(The max number of users).  The first chunk (in the .mdb) relates to the
first 64 byte chunk in the .ldb.  The smaller chunks in the .mdb are changed
based on the users activity.  

Actual record locks on the database are stored in the .ldb too, but in a
very odd way.  When I first read about it, I thought it was the oddest
thing.  Basically, the max size of an .ldb is going to be 16k.  (255*64).
However, there is a 'virtual' size of the .ldb.  If Jet needs to lock
something in the 25th megabyte of an .mdb, it creates a lock on that
position in the 'virtual .ldb', even though the .ldb isn't that big, file
read/write code can lock bits outside a file's actual space.  This prevents
any read/write locks on the actual .mdb.

Drew

-----Original Message-----
From: JWColby [mailto:jwcolby at colbyconsulting.com]
Sent: Friday, February 02, 2007 10:31 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Connections and Performance

No, but the lock file does (LDB).  I have never really figured out how.  If
you open it in a text editor it is mostly empty.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Friday, February 02, 2007 11:20 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Connections and Performance

I've certainly had more than 5 FEs connected to a single BE.  The back end
doesn't keep track of connections in Access.

Charlotte Foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Friday, February 02, 2007 5:58 AM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] Connections and Performance

I've read several times that maintaining a connection between a FE and a BE
will increase the performance of the FE because it doesn't need to reconnect
before transferring data.  The connection here would be a bound form
connected by a table link to a table in the BE.

But, the connection limit for one BE is 5 FE's.  So, will maintaining
connections on more than 5 FE's reduce performance?  Seems logical, but I
was wondering if this is correct or is there more to it?

Thanks!

Dan Waters

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list