On 04/07/07, Rod Dunne <[EMAIL PROTECTED]> wrote: > I tried the nested 036 library also and it suffers from the same > symptoms. I'll attach the call stacks at the end in case you are > interested to see the failure points.
Hi Rod. I'm not sure how much I'm going to be able to help here, as SQLite is a tricky thing to use on a network share. Over NFS the general advice for SQLite is: don't. As for the apple file sharing protocol, which I assume you are using, it is a complete mystery to me. One possibility is the file sharing protocol ignores byte-level locking and simply hands out a full file lock to the first computer and the second can't get to it (I assume you have more than one computer involved). It may sound silly, but have you tried using Windows file sharing? It's just as easy to setup on a mac, and I know it has acceptable byte-level locking when correctly configured, though many default samba configurations have byte-level locking turned off, as older versions of windows (95/98) struggle with notions of "integrity". > Rather than use the SQLite 3.4.0 > source, I told it to link against Apple's internal dynamic SQLite 3.0 > library and I named the target libsqlitejdbc.jnilib. > > When I replaced your runtime library with this one, the file locking > problems _seemed_ to go away. So you get these locking issues on both the native and nested versions of the driver? It would definitely be a good idea to debug with the native drivers, as the nested version adds extra complexity to the file locking code. As for Apple having special locking in their version, I really doubt it. SQLite locking is very complicated, replacing it would be no mean feat, and a real waste of time as drh has done a very nice job of it. Could you show me the errors you get using the native version of the driver? d. --~--~---------~--~----~------------~-------~--~----~ Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
