Icon View Incident Report

Serious Serious
Reported By: Rob Grundy
Reported On: 2/20/2013
For: Version 4.34 Build 7
# 3726 Multi-Threaded Creation/Dropping of In-Memory Tables Can Cause Access Denied Error Message

We're just stress testing our latest release prior to sending it out and I'm noticing some errors in the database. We're testing with 4.34 build 7, and after ~700 iterations through the test cycle we're getting DBISAM Engine Error # 11013 Access denied to table or backup file ''etsAD0B85443908469B813664CF4CAD0CDF''

The table in question is an in memory table, and to avoid potential naming conflicts (as it's run from a function in a soap backend server) it's actually called ets+(GUID) as is the session name etc to keep it all nicely thread safe. The database, session and query components used in the function that tripped the error are all dynamically created and the naming parameters are based on a guid generated at function entry.

The SQL being executed is a select into the memory table, and due to the naming convention we are fairly confident that the name of the table is unique and cannot be open already.

This error occurred initially after about 700 iterations, then again half an hour later after around 850 iterations with a different named table. There would have been subsequent successful executions of the same function inbetween.

Shortly after that we two similar access denied errors in a standard background update cycle, one dropping an in memory table, and 5 mins later another selecting into an in memory table. The background update cycle had been running on that server against the same database every 60 seconds for the past 5 days. The memory tables involved in these two are static names as they are only accessed from the one background update thread, so should never have an access issue as only one instance of that thread can be running.


Comments Comments
This problem was caused by the fix in incident #3710 that related to freeing the in-memory lock file. What would happen is that one thread would run into an issue where it couldn't create the lock file, and would flag the database as read-only as a result. The approach to fixing #3710 has been changed so that it only tries to clean up in-memory lock files once there are no sessions present on the server, similar to what is done with other in-memory table files.


Resolution Resolution
Fixed Problem on 2/22/2013 in version 4.35 build 1


Products Affected Products Affected
DBISAM ODBC Client-Server
DBISAM ODBC Client-Server with Source
DBISAM ODBC Standard
DBISAM ODBC Standard with Source
DBISAM ODBC Trial
DBISAM VCL Client-Server
DBISAM VCL Client-Server with Source
DBISAM VCL Standard
DBISAM VCL Standard with Source
DBISAM VCL Trial

Image