|
History
| Log In
|
|
|
|
The file lock looks justified to me - the missing lock in 5.5 just covered the actual bug: Both clients would open db4o instances against the same file in this scenario. :/ Currently, ServerMessageDispatcherImpl#switchToFile() unconditionally opens a new ObjectContainer instance. Naive fix proposal: Keep a "global" map of files -> alive container instances (in ObjectServerImpl? along with their attached client/transaction count?), and grab a transaction from there if the file is already in use.
Exception occured using latest db4o-6.3.1.0 with latest testcase attached for .Net2.0
------------------------------------------------------------------------------------------------------------------ 'formula2.yap' closed at Db4objects.Db4o.Internal.CS.ClientObjectContainer.ExpectedResponse(Msg expectedMessage) at Db4objects.Db4o.Internal.CS.ClientObjectContainer.SwitchToFile(String fileName) at TestCase00001293.Program.Main(String[] args) in D:\SalesForce Cases\case00001293\TestCase00001293\Program.cs:line 32 Problem is reproducable against db4o-6.1.300.0, db4o-6.1.501.0 and db4o-6.2.101.0
Problem is not reproducable against db4o-6.1.1.0 (6.1.001) and db4o-6.0.200.0 Fixed in svn trunk, pending concurrency review and decision whether to port back to 6.1.
Where can we find the fixed version, to pass it on to the customer.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
switchToFile() shared client failure
Msg.SWITCH_TO_FILE failed.
com.db4o.DatabaseFileLockedException: /home/patrick/workspaces/db4o/test/formula2.yap
at com.db4o.internal.JDK_1_4.lockFile(JDK_1_4.java:35)
IIRC file locking has been fixed to explicitly take care of VM-internal (or better: classloader-internal, as far as Java is concerned) locks through a dedicated map in JDK_1_4#lockFile(). This seems to "fire back" here. Will check whether there's just some unlock call missing or whether there is a bigger, conceptual issue.