-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Campbell Boucher-Burnet" <[EMAIL PROTECTED]> writes:
<snip/>
>
> If my conclusion that hsqldb never creates the "database name".lock file is
> corrent, then the last modified code is, as far as I can tell, useless. It
> seems to do nothing more than waste 3 seconds every time the method is called,
> since "if (l1 != l2)" can never be satisfied (it will will always be
> equivalent to "if(0L != 0L).").
>
> Is the f.lastModified code simply a remant that represents something that
> never got completed in hsql1.4 and that nobody has ever looked at since? I
> suspect so.
This was my thinking...
> Anyway, looking at the rest of the code, it would seem that the test basically
> closes the FileInputStream on the .properties file and tries to delete it,
> stating that the database is open by another process if it cannot delete the
> file after closing it's own Stream on it.
>
> My gut says this sounds really flaky. Lets go hunting some more...
Is the .properties file always there? I think it should also check that the
file exists!
<snip/>
> Also, it is unclear to me precisely how long it takes on every platform to
> release a lock on a file, once a stream on it has been closed. I presume that
> XXXStream.close should not return before the OS has actually garanteed that
> the file is released completely. But perhaps there is another strange timing
> issue here that occasionally results in the delete request being processed
> before the close has actually resulted in the OS fully releasing any native
> locks on the file. Could this be another race condition? For sure, I have
> experienced less than perfect file locking timing issues under Win32 before
> under FAT/FAT32 (as opposed to NTFS, which seems to be pretty stable in this
> respect).
This is actually what I am thinking... my gut tells me that my ReiserFS under
Linux is probably handling this correctly. Of course this could just be my
prejudice against windows talking...
One way to test it would be to use a synchronize isAlreadyOpen method. I might
actually try that next. It would slow down Hypersonic but a slow reliable
database is always better than an unreliable fast database.
> I think the way to resolve this might be:
>
> 1.) actually create the .lock file if it does not exist (DUH!), and call
> deleteOnExit() against it after creating it.
hm.. would require documentation updates. If someone kills the VM without a
proper shutdown your file won't get deleted. We would need to explain how to
remove the .lock file.
I don't really have an objection to this though.
> This garantees that:
> - we will fail to create it if it already exists (must be that another
> instance has created it and is still running or the hosting VM has crashed
> after allowing another instance to mount the database, but before normal
> shutdown of the instance, which should delete the lock file as the last
> operation of a normal database shutdown)
> - if we do create it, it will be deleted on normal termination of the VM, even
> if the database engine reaches a non-functioning state before that time.
<snip/>
I was thinking of this. It would require that users delete a .lock file every
once and a while. Not too bad.
> 2.) If the lock file exists, then either another instance really does have the
> database open (remember, createNewFile is apparently garanteed to be atomic),
> or the VM hosting the last instance that mounted the database crashed (or some
> fool user created the file, external to the engine...sorry, there is no way to
> account for user error).
If it is atomic... then it needs to be synchronized... which means slower
starup. It might be better to just synchronize in isAlreadyOpen.
Remember... we think this is a bug in the filesystem... so createNewFile might
now work...
> In either case, a simple solution is to refuse to start up until the file is
> deleted (the other process shuts down normally, the VM is terminated normally,
> or an admin realizes that the last instance's VM crashed and manually deletes
> the lock)
>
> 3.) Anybody have a good algorithm for a better cooperative file locking
> protocol?
Hm... we could also do the normal wait to see if .lock is modified.. a running
DB could touch it every once in a while.
Normal UNIX lock files have a PID. If another process starts, it sees the
.lock file, reads the PID and checks if the process still exists. If it does
it can refuse to load.
This is one of the better ways to do it but under Java there really isn't any
way of doing this.
> Refusing to start up if the lock file exists defeats the automatic recovery
> feature of hsql(db) somewhat, as it still requires a small amount of manual
> intervention that may not be available if controlling things remotely or in an
> qautomated fashion when controlling an embedded hsqldb instance from a
> super-server.
We could spin for a little while until we are sure that no other VM is
modifying the .lock.
> So, is it garateed on all operating systems that an attempt to delete a file
> open for write will fail?
No... we can not..
> If so, we can discriminate between a previous crash and a currently mounted
> database by attepting to delete the lock file That is, perhaps if an instance
> keeps a write stream open on the lock file unil after normal shutdown, we
> could use File.delete or File.canWrite() to do the test. If we have already
> garanteed that the lock file exists, is it garanteed on all platforms the
> File.delete or File.canWrite() will return false if the file is already open
> in write mode elsewhere (e.g. in another process or by a XXXFileStream in the
> same VM)?
I don't think so. I have read (need to find it) that this is not gauranteed.
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/
Copyright exists to improve science not to preserve the rights of the author.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8h7rfAwM6xb2dfE0RAs6PAJ94cAWejY+xB3YXuGkNxYs9gV9JjQCfX2Nf
clmdIOyxuADAF4bNLfVYh7M=
=z44C
-----END PGP SIGNATURE-----
_______________________________________________
hsqldb-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
