InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

Hi InstantDB Experts -

(Using InstantDB v3.12 with the RmiJdbc driver)

I'm just wondering if anyone can shed some light on whether seeing lock
counts greater than one is expected or unusual.  Lock counts are visible
when you have TR_TRANS debug flag set.

To ensure that we're properly releasing JDBC resources, we've (temporarily)
gone to great pains to ensure that we are opening a connection, creating a
statement, executing *one* query or insert or update, fully reading the
result set if any, closing the result set, closing the statement and
finally closing the connection.  As such, I wouldn't expect that lock
counts for any table would ever climb above one, yet we're seeing that occur.

BWT, by "fully reading the result set", I mean we call next() on the result
set until it returns false before closing the result set.  If this isn't
sufficient to completely read the result set (to avoid InstantDB retaining
locks on the related tables), what is the correct way to do fully read a
result set?

Here's a small chunk of Instant DB output generated during a session.  In
this case, we were running a reference data loader which is basically a
Java program that creates a bunch of reference data to pre-populate the
database with.  As far as SQL execution goes, it ends up being a mix of
SELECT, INSERT and the occasional UPDATE.

Note that the lock counts are, in this case, both 36.  I've seen lock
counts in the low hundreds.

RMI TCP Connection(41)-10.2.1.9 SELECT owned FROM FoodTypeFood WHERE owner
= 1092
RMI TCP Connection(41)-10.2.1.9 Trans 1550 locked table: FoodTypeFood Lock
count=36
RMI TCP Connection(41)-10.2.1.9 Checking transaction autoCommit:
callersID=669,cur ID=669
RMI TCP Connection(41)-10.2.1.9 Checking transaction autoCommit:
callersID=669,cur ID=669
RMI TCP Connection(41)-10.2.1.9 Checking transaction autoCommit:
callersID=670,cur ID=670
RMI TCP Connection(41)-10.2.1.9 SELECT owned FROM FoodTypeSubtype WHERE
owner =1092
RMI TCP Connection(41)-10.2.1.9 Trans 1550 locked table: FoodTypeSubtype
Lock count=36
RMI TCP Connection(41)-10.2.1.9 Checking transaction autoCommit:
callersID=670,cur ID=670
RMI TCP Connection(41)-10.2.1.9 Checking transaction autoCommit:
callersID=670,cur ID=670

Does this seem strange?  Should it be a concern?  Does it indicate that
resources are not being properly released?

Thanks for any help.

Dave Muirhead


To unsubscribe from this list, please send an
email to 'majordomo@smartcard.co.uk' with the text
'unsubscribe instantdb' in the message body.