(This issue is not regarding concurrent ODB-File Access.)

OOO Versions: I've seen that issue in various OpenOffice Versions since one of
the first releases of v2 and this behaviour still exists in v3.2. With the
current version OOO320m12 (Build 9483) I am able to reproduce this behaviour
with every Mail Merge. (In other words: I can't remember one Versions since v2
which did not behave like that.)

OS (32bit): Windows XP SP3 (up-to-date patches), Windows 2000 (up-to-date patches)

JRE (32bit): I'm currently using 1.6.0_18, but older versions of JRE 1.6 doesn't
seem to have any influence on the issue.

File Location: Doesn't seem to matter. Issue occures on local NTFS volume and
samba shared volume (mapped withe a drive letter).

What you need for testing (you can use attached openoffice documents instead,
but you have to register the attached test.odb!):
 1.Create a new OpenOffice DataBase "test.odb"
 2.Register Database in OpenOffice
 3.Open Database, create a table, insert a few fields, generate some random
datasets, close the Database
 4.Create new writer document "test.odt"
 5.Insert the Database Fields into the writer document, save the document and
close it
 6.Create another OpenOffice Document – for example: Generate a calc Document
without content and save it as "xyz.ods"

How to reproduce the issue?
User A:
 1.Open at least one existing writer or calc document (the content doesn't
matter as described in step 6 above); for this testing lets take an empty calc
document and we save it as "xyz.ods" <-- without that step, the error is
sometimes not reproducable! -->
 2.Open "test.odt"
 3.Press printing and answer the question regarding Mail Merge with "yes"
 4.select one (or all) dataset of the test.odb database
 5.print the mail merge
 6.close the "test.odt", but keep the other openoffice document ("xyz.ods") opened!
 7.try to rename the "test.odb" – it will fail, because there's still a lock on
the file although there doesn't exist any *.lck file anymore!
User B:
Now, if another user tries to access the ODB-File (let's say User B tries to
access the file over a network share), he will get an Java Error Message (->
look at the attached Screenshots) and will not 
be able to read (view) or write anything in the ODB-File. The ODB File is still
locked, although there currently doesn't work anybody with it.
User A is the only one who can remove the file lock (and who is still able to
open and edit the ODB-File at this time): At least he needs to close every
remaining OpenOffice window (in this example: the remaining xyz.ods). Do that
and retry renaming the test.odb - in some cases User A needs to stop the
quickstart utility, too!

Due to this behaviour normal users often lock a ODB file on a network share for
a few hours, although they actually worked with the file only a few minutes.
I've seen users regularly locking ODB files for the whole day because of this
behaviour. This issue is clearly not regarding concurrent ODB access.

While reproducing this issue I realised, that the above described steps 4 and 5
aren't necessary to generate the persitent file lock. It is enough to open the
mail merge window (= start printing and answer yes to mail merge).