[ic] "GDBM could not tie to access.gdbm"

Gert van der Spoel gert at 3edge.com
Sun Aug 23 13:50:13 UTC 2009


> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of Jon Jensen
> Sent: Saturday, August 22, 2009 3:13 AM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] "GDBM could not tie to access.gdbm"
> 
> On Thu, 20 Aug 2009, Stefan Hornburg wrote:
> 
> >> I found too much contention for that table when it's in DBM, so I
> >> recommend you move it into your SQL database instead where this
> isn't a
> >> problem.
> >
> > I agree. What about a patch for standard catalog?
> 
> On this topic, does anyone know why the MySQL definition for the access
> table includes this additional parameter?
> 
> Database            access          IC_LOCKING        1
> 
> The access table is still a DBM table by default even when using MySQL
> as
> it is for Postgres and SQLite definitions too, so I wonder why that's
> there.
> 
> Jon

My assumption is that it was put there by someone who mainly uses MySQL as
their database of choice for Interchange. 

According to Whatsnew 4.9:
* Add internal Interchange locking routines and support for GDBM. (Should
  work on others as well but is not tested.)

  To set internal locking, just put in the config:

        Database access IC_LOCKING 1

  On GDBM, employs the GDBM_NOLOCK parameter.

  It should prevent the errors in access.gdbm when multiple admins are
  logged in. It might also serve to make userdb in GDBM somewhat usable.


When you do not have this line and using GDBM for your access file and 2
people/processes are trying to use access.gdbm, the second process will have
a problem (2 admin users, one will get a 500 error screen for example). This
line will prevent this from happening and I suppose it should have been
added in the pgsql and sqlite versions as well ... 

And if I am seeing the code correctly then in lib/Vend/Table/Common.pm the
sub's   lock_table and unlock_table are depending on this variable being
set. If not set I suppose locking will depend on for example if MySQL itself
performs certain kinds of locking on the table during certain actions ... 

CU,

Gert








More information about the interchange-users mailing list