- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SQLite3 and locking
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 09:59 AM
тАО04-16-2008 09:59 AM
Our first simple test on OpenVMS V8.3 is to just open two sqlite3 sessions on the same database file. The second one fails to open the file, presumably because by default an open in CRTL opens for exclusive access, unlike on Windows or Linux.
Our second test was on OpenVMS V7.3-2 with the DECC patched up to ACRTL V3.0. When we tried to open a single sqlite3 session on a database file it failed, issuing this error:
$ sqlite3 foo.db
SQLite version 3.5.7
Enter ".help" for instructions
sqlite> create table bar(a,b);
SQL error: database is locked
While we can accept for the moment that we may not be able to get this to work at all on VMS V7.3-2 (though we would really like it to work there,) it is crucial that we solve the file locking problem before we can proceed. Can anyone help with either problem?
Thanks,
Ben
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 10:36 AM
тАО04-16-2008 10:36 AM
Re: SQLite3 and locking
One of the things I was told that should be checked (and altered) was just the flck functionality - that seems to work differently on Unix. I understood that flck uses posix-based locking. IIRC, Posix locks are user-mode locks on byte ranges. To have this working properly on OpenVMS, you may have to redesign the relevant functions in os_vms.c to behave like expected by SQLite.
It may well be that these locks are the different behaviour between CRTL on OpenVMS 7.3-2 and 8.3. It should be pointed out in the CRTL documentation.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 10:48 AM
тАО04-16-2008 10:48 AM
Re: SQLite3 and locking
I have already fix this. But I have found another problem I'm trying to solve.
If a program open twice the database the second connexion failed with a disk I/O error.
JF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 10:54 AM
тАО04-16-2008 10:54 AM
Re: SQLite3 and locking
Thanks,
Ben
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 11:05 AM
тАО04-16-2008 11:05 AM
Solutionhttp://hg.vmspython.dyndns.org/vmspython/rev/cda4c8dae858
Let us know is this work (no database corruption when 2 sessions update simultaneous a database).
JF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2008 02:12 PM
тАО04-16-2008 02:12 PM
Re: SQLite3 and locking
$ define DECC$FILE_SHARING ENABLE
would do the same thing. It's more robust to have the change actually in the code and not depend on the environment, but then you have to maintain your changes.
When a porting issue can be taken care of entirely by a feature setting, the intersection of most robust and most maintainable is probably to call decc$feature_set_value from within a LIB$INITIALIZE psect that you link into your application. This isn't always feasible with a library that may be linked in by many applications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2008 06:12 AM
тАО04-17-2008 06:12 AM
Re: SQLite3 and locking
Now as a subgoal of this project we want to reach back as far as we can in our supported client base. The current floor version we support is V7.1. We found when we went back that far (building on a V7.3-2 system against V7.1 libraries) we had compile errors relating to big file support. And when we tried on V7.3-2, we had the runtime problem mentioned earlier in this thread, i.e. "Database is locked" (single process only).
We don't really need big file support, as the databases are going to be small. I'm wondering if we could make sqlite3.exe in two flavours, a small file and a big file version. How much work would that take?
Are there any other "show stoppers" that would prevent us from supporting all of the way back to V7.1? Would we be able to get some kind of locking working that far back (not necessarily Posix)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2008 10:05 AM
тАО04-17-2008 10:05 AM
Re: SQLite3 and locking
I agree that the use of DECC$FILE_SHARING ENABLE is simpler but this is a global setting and as sqlite is an embedded library this will affect other library. In this case the Ruby interpreter.
Python use the LIB$INITIALIZE solution and the behavior can be change using python_xxx logical, for example PYTHON_FILE_SHARING, so this will not interact with others programs.
Ben,
sqlite work on OpenVMS 7.3-2 using the latest acrtl patch, I have include it in Python and it pass all tests except those using multiple connexions.
to remove the support of large file just compile without the _LARGEFILE define.
JF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2008 10:10 AM
тАО04-17-2008 10:10 AM
Re: SQLite3 and locking
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2008 01:27 PM
тАО04-17-2008 01:27 PM
Re: SQLite3 and locking
You're correct it work on VMS 8.3 which is the minimum version supprorting byte range locking using fcntl anf F_SETLK and it don't work on 7.3-2 which doesn't have this feature.
Sorry my mistake...
JF