Re: sometimes .h2.lock file is not removed

1,729 views
Skip to first unread message
Message has been deleted

Thomas Mueller

unread,
Jan 19, 2013, 8:13:37 AM1/19/13
to H2 Google Group
Hi,

I think you are right, there is a possibility that the file is re-created during the unlock() method. I will fix this.

> The writer opens an H2 connection, writes the data, and closes the connection.

If you do that a lot, it will be slow.

Anyway, even if the file is not deleted, it should not be a huge problem. The only problem is that opening the connection the next time will be slower. But it should still work.

Regards,
Thomas



On Fri, Jan 18, 2013 at 5:26 PM, Miles Reucroft <reuc...@optonline.net> wrote:
We have an app with a single H2 writer. The writer is an rmi server and receives requests from multiple clients. The writer opens an H2 connection, writes the data, and closes the connection. This seems to work fine for the most part. Occasionally, we see under heavy loads that the .h2.lock file doesn't get removed. Very rarely happens but we can't see a scenario where we're not closing the connection.
 
My question is the following: looking at FileLock.java in the 1.3.66.1 vintage of H2, I see in the unlock() method that the lock file is removed before the watchdog thread is stopped. Doesn't that leave a small window open for the watchdog thread to recreate the lock file resulting in the dangling file? Shouldn't the watchdog thread be stopped first and then the file removed?

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/dynGVIB3fTQJ.
To post to this group, send email to h2-da...@googlegroups.com.
To unsubscribe from this group, send email to h2-database...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.

Miles Reucroft

unread,
Jan 22, 2013, 8:47:46 AM1/22/13
to h2-da...@googlegroups.com
Thanks for looking. The other piece of the puzzle is that we have a lot of reader processes that try to open read only connections to the data. They seem to have errors when the lock file is present.

Thomas Mueller

unread,
Jan 23, 2013, 2:34:36 PM1/23/13
to H2 Google Group
Hi,

Opening and closing the database is very slow. Couldn't you use the server mode, and only open and close the database once?

Regards,
Thomas



--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/qxvdWDNaEFcJ.

Miles Reucroft

unread,
Jan 24, 2013, 12:48:11 PM1/24/13
to h2-da...@googlegroups.com
To clarify, for any particular db file, the server only opens and closes once. We don't seem to notice any performance issues. However, our server does create a number of different h2.db files and during those heavily loaded conditions we will get a dangling lock file which causes issues for the reader processes. So the issue we really have is how we can avoid the dangling h2 lock file.
Reply all
Reply to author
Forward
0 new messages