25
Replies
I know all that since I read all that.
However, file locking is an issue only if multiple instances try to access the DB. I assume that LR uses one queue to access the DB and therefore is like a single instance access to the DB. So, if single access can be controlled by not running multiple LR on the same catalog ..
From here: http://www.sqlite.org/faq.html#q5
You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.
It's everybody's own decision to take a shot .... when a good backup is in place 
here the offical FAQ: http://www.sqlite.org/faq.html#q5 :
Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.
True BUT: http://en.wikipedia.org/wiki/ISCSI :
In computing, iSCSI (
i/aɪˈskʌzi/ eye-skuz-ee), is an abbreviation of Internet Small Computer System Interface, an Internet Protocol (IP)-based storage networking standard for linking data storage facilities. By carrying SCSI commands over IP networks, iSCSI is used to facilitate data transfers over intranets and to manage storage over long distances. iSCSI can be used to transmit data over local area networks (LANs), wide area networks (WANs), or the Internet and can enable location-independent data storage and retrieval. The protocol allows clients (called initiators) to send SCSI commands (CDBs) to SCSI storage devices (targets) on remote servers. It is a storage area network (SAN) protocol, allowing organizations to consolidate storage into data center storage arrays while providing hosts (such as database and web servers) with the illusion of locally attached disks.[1]Unlike traditional Fibre Channel, which requires special-purpose cabling, iSCSI can be run over long distances using existing network infrastructure.[2]
>>>> so there no reason why the SCSI/SAN solution not works. But of course if you startup a secon client then probply you have Problem...
>>>> But from this point of view i think the changes in SQL for a multiuser support for LR5 arent that high if you use ISCSI, but i think when u read that:
.....But experience suggests that most applications need much less concurrency than their designers imagine....
then it's nearly ridiculous to belive tha probably up to 5 editor@the same time edit the same project, generats the amount of Problem as 500 enterprise clients. So IMHO the engineers anwser is groggy... There is shorter way implement that Multiuser feature that "adobe" / "the engineers" say. But You need ISCSI or somthing comparable and thats relative complex to set up and expensive. And then i think PM/Marketings says too complex with SQLite, MySQL amongs ORACLE (-> dangerous), and the rest of relatonel database to expensiv and in general only 1% of the LR will it use... ->so: End of story
but i think i will run some automatet ISCSI tests and will report..
regards stephan
AdChoices