Re: [sqlite] multiuser DB on network share
Thankyou for the excellent reference. Roger Binns wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Stanton wrote: An elegant explanation. Write a book about it! Chris Hertel already did. This is the bit about oplocks: http://ubiqx.org/cifs/SMB.html#SMB.10.1 The index has pointers to a few other places where oplocks are discussed. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpqAkmOOfHg372QQRApJRAJ9TfRMbxzil1r5/MNUCVZkx/WqmqwCeNi7q jxrX6PIqQ+AXwWnGlbSBruM= =aQTN -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Stanton wrote: > An elegant explanation. Write a book about it! Chris Hertel already did. This is the bit about oplocks: http://ubiqx.org/cifs/SMB.html#SMB.10.1 The index has pointers to a few other places where oplocks are discussed. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpqAkmOOfHg372QQRApJRAJ9TfRMbxzil1r5/MNUCVZkx/WqmqwCeNi7q jxrX6PIqQ+AXwWnGlbSBruM= =aQTN -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
The daemon would behave just like a well trained Sqlite application on the host. Local ODBC clients could access it through localhost and remote ones through a well known port. It would have some security on the remote connections. Existing Sqlite applications would operate transparently by just linking in the library with the remote interface (redirector). I notice from this forum that the general concept of sharing a resource like a file (which is what Sqlite is doing) is poorly understood, the source of chronic confusion and the target of a host of Heath Robinson/Rube Goldberg solutiins. I seem to recall that file sharing on VMS was achieved by such a mechanism and worked quite effectively. Fred Williams wrote: That's an interesting proposal. Done right, the SQLite base module could remain the same and all the "new" code could be an optional, stand alone, add on. Fred -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 9:24 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] multiuser DB on network share An Sqlite redirector which runs as a daemon on the machine hosting the DB and has an API which provides the Sqlite API calls for remote clients would solve these networking problems and maintain application code compatibility. The sqlite3_open call would detect that the DB was remote and the rest would be handled by the library. A model would be the way Samba provides an SMB connection to a Unix file system for SMB clients. An sophistication would be to also implement the standard SQL/CLI API (also known as ODBC). This approach would not only make the networking nightmares disappear but also give seamless integration with ODBC applications. Dr Gerard Hammond wrote: Daniel Önnerby wrote: > So what you are saying is that opening a SQLite DB on a shared network > drive SHOULD work with multiple clients (if all servers and NFS-version > are updated to most recent version)? I have found that accessing a FileMaker Pro DB file, on a shared network drive, simultaneously from a Mac (via AFP over IP) and PC (via SMB), leads to an immediate corruption of the file. Nice. I hope the SQLIte db file doesn't suffer the same behaviour by assuming a single network protocol-level locking mechanism. -- --- To unsubscribe, send email to [EMAIL PROTECTED] -- --- - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
An Sqlite redirector which runs as a daemon on the machine hosting the DB and has an API which provides the Sqlite API calls for remote clients would solve these networking problems and maintain application code compatibility. The sqlite3_open call would detect that the DB was remote and the rest would be handled by the library. A model would be the way Samba provides an SMB connection to a Unix file system for SMB clients. An sophistication would be to also implement the standard SQL/CLI API (also known as ODBC). This approach would not only make the networking nightmares disappear but also give seamless integration with ODBC applications. Dr Gerard Hammond wrote: Daniel Önnerby wrote: > So what you are saying is that opening a SQLite DB on a shared network > drive SHOULD work with multiple clients (if all servers and NFS-version > are updated to most recent version)? I have found that accessing a FileMaker Pro DB file, on a shared network drive, simultaneously from a Mac (via AFP over IP) and PC (via SMB), leads to an immediate corruption of the file. Nice. I hope the SQLIte db file doesn't suffer the same behaviour by assuming a single network protocol-level locking mechanism. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
An elegant explanation. Write a book about it! Roger Binns wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Sprenkle wrote: This sounds exactly like what causes the trashed shared MS Access databases I've seen and network locking issues I see warnings about here. No it isn't. How is this supposed to work correctly without the client being notified? Err, the client OS is notified with an oplock break. If I write an application that requires serialized access to a file, and I rely on operating system locking, if the operating system drops my locks without notifying me my design breaks. You are totally confused. The application talks to the client OS (kernel). The abstraction is a kernel interface and file handles. The kernel then has a provider for the relevant filesystem. That provider then talks to a block layer or over the network. Oplocks etc are happening in that second part. They are not application visible. (1)Application <= (2)kernel => (3)redirector <= (4) network server Oplocks are something available in the SMB protocol (and recent NFS versions) between 3 and 4. They allow the redirector to optimize in the case when it is the only client with the file open. For example if oplocks are not available, then every read/write/lock request from the application (1) gets to the redirector (3) which has to contact the server (4) in order to satisfy the request. If the server (4) grants an oplock to the redirector (3) then that redirector knows it is the only client of the server with the file open. Therefore file contents cannot change so it can cache file content information. Similarly it can also do all byte range locking internally since no other client has the file open. If another client requests to open the file, then the server (4) sends the oplock break to the first redirector which will discard cached file contents and apply byte range locks it was handling internally, before acknowledging the oplock break. From that point on it has to send all read/write/lock requests to the server since the other client(s) could be modifying the file. At no point in all of this is the application(1) aware of oplocks, nor does it have any control over them. Heck even the kernel (2) doesn't know. It just hands all requests to the redirector (3) which can use oplocks to optimize performance. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpdWdmOOfHg372QQRArwkAKC+NX8C8KTBtL5DVKNZbefZ0W/VTACgi7Kr JBlumHql+rsB0AbjG/5NNpM= =YNJF -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Sprenkle wrote: > This sounds exactly like what > causes the trashed shared MS Access databases I've seen and network locking > issues I see warnings about here. No it isn't. > How is this supposed to work correctly without the client being notified? Err, the client OS is notified with an oplock break. > If I write an application that requires serialized access to a file, and > I rely > on operating system locking, if the operating system drops my locks > without notifying me my design breaks. You are totally confused. The application talks to the client OS (kernel). The abstraction is a kernel interface and file handles. The kernel then has a provider for the relevant filesystem. That provider then talks to a block layer or over the network. Oplocks etc are happening in that second part. They are not application visible. (1)Application <= (2)kernel => (3)redirector <= (4) network server Oplocks are something available in the SMB protocol (and recent NFS versions) between 3 and 4. They allow the redirector to optimize in the case when it is the only client with the file open. For example if oplocks are not available, then every read/write/lock request from the application (1) gets to the redirector (3) which has to contact the server (4) in order to satisfy the request. If the server (4) grants an oplock to the redirector (3) then that redirector knows it is the only client of the server with the file open. Therefore file contents cannot change so it can cache file content information. Similarly it can also do all byte range locking internally since no other client has the file open. If another client requests to open the file, then the server (4) sends the oplock break to the first redirector which will discard cached file contents and apply byte range locks it was handling internally, before acknowledging the oplock break. From that point on it has to send all read/write/lock requests to the server since the other client(s) could be modifying the file. At no point in all of this is the application(1) aware of oplocks, nor does it have any control over them. Heck even the kernel (2) doesn't know. It just hands all requests to the redirector (3) which can use oplocks to optimize performance. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpdWdmOOfHg372QQRArwkAKC+NX8C8KTBtL5DVKNZbefZ0W/VTACgi7Kr JBlumHql+rsB0AbjG/5NNpM= =YNJF -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
> How is the first client 'contacted' and asked to respond? > I can't see how this is anything but useless. I can't imagine very many > programs honor this kind of request since I've never even heard of this > before last week. If the first client doesn't respond to the request > it would have to degenerate to a standard lock. Is this an OS hack > designed in for a specific microsoft application? I said client OS, not program. It is part of the SMB protocol and the client operating system includes an SMB implementation. Under Windows it is called the SMB redirector. The specific protocol request is named oplock break. Any SMB implementation that uses oplocks (they have to be specifically requested at time of open by the SMB implementation) also has to implement the oplock breaks. How is this supposed to work correctly without the client being notified? If I write an application that requires serialized access to a file, and I rely on operating system locking, if the operating system drops my locks without notifying me my design breaks. This sounds exactly like what causes the trashed shared MS Access databases I've seen and network locking issues I see warnings about here. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
On 1/10/07, Nuno Lucas <[EMAIL PROTECTED]> wrote: > How is the first client 'contacted' and asked to respond? > I can't see how this is anything but useless. I can't imagine very many > programs honor this kind of request since I've never even heard of this > before last week. If the first client doesn't respond to the request > it would have to degenerate to a standard lock. Is this an OS hack > designed in for a specific microsoft application? The client is the SMB/CIFS file system driver, not the application. It is all transparent to the programmer, and that is the problem, because if the operating system doesn't handle this well (in other words, is bugged) the programmer has no idea it's corrupting it's own file. So it sounds like turning them off ( they mentioned a windows registry change in one web page ) would be a good idea if you wanted to ensure database integrity on a shared directory. The whole idea is actually quite clever, but the problem is that it was idealised before people understood everything about networked file systems (the security aspect was completely overlooked at the beginning). The current versions are quite good, but as they have to be compatible with older clients (Win9X), a lot of hacks need to be done (not forgetting it was done in a time Microsoft didn't believe in the future of TCP/IP). For better or worse, is still the major network file system for small networks (and I don't see any future change on this). Thanks for the info. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Sprenkle wrote: > How is the first client 'contacted' and asked to respond? > I can't see how this is anything but useless. I can't imagine very many > programs honor this kind of request since I've never even heard of this > before last week. If the first client doesn't respond to the request > it would have to degenerate to a standard lock. Is this an OS hack > designed in for a specific microsoft application? I said client OS, not program. It is part of the SMB protocol and the client operating system includes an SMB implementation. Under Windows it is called the SMB redirector. The specific protocol request is named oplock break. Any SMB implementation that uses oplocks (they have to be specifically requested at time of open by the SMB implementation) also has to implement the oplock breaks. Note that if a client refuses to respond to an oplock break, the server will eventually timeout and break the whole TCP connection (ie forcibly disconnect the client). > Degenerate cases? This sounds like something only Microsoft could dream > up, so I guess degenerate applies... ;) The degenerate cases are due to poor design of the signing implementation. SMB signing as a security solution has so many loopholes that I don't know why people both. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpRijmOOfHg372QQRAmW7AJoCjr5wGUTfX7GSn1mrAFAkmO5exwCfTa0w NXz27LvxqL3Xu0hkgq+wwVw= =scgT -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
John Stanton wrote: There are definite locking issues with some implementations of NFS. Every time I see this NFS locking issue mentioned I wonder if there is a tool which can determine whether the issue actually exists on a particular system. Martin - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
> Oplocks do not break things. Oplocks will guarantee consistency. They > are granted when only one client OS has a file open letting that client > OS perform locking and caching operations internally without consulting > the server each time. If another client wants to open the file, then > that second open request is held up by the server, the first client > contacted and asked to flush any outstanding data, acquire locks, and > drop the oplock. Once that has happened then the second client gets the > answer to its open request. How is the first client 'contacted' and asked to respond? I can't see how this is anything but useless. I can't imagine very many programs honor this kind of request since I've never even heard of this before last week. If the first client doesn't respond to the request it would have to degenerate to a standard lock. Is this an OS hack designed in for a specific microsoft application? The client is the SMB/CIFS file system driver, not the application. It is all transparent to the programmer, and that is the problem, because if the operating system doesn't handle this well (in other words, is bugged) the programmer has no idea it's corrupting it's own file. One advantage of using a samba server for this is that you can configure each share and even fake oplocks (meaning just ignoring) on read-only media (like a shared CD/DVD drive), meaning substantial performance improvements (the data can be all cached on the user OS). > There are other forms of oplocks that allow for opening and closing the > file multiple times without consulting the server as well as some forms > of limiting sharing (dropped when clients start using byte range locking). > > There have been some problems with Windows when smb signing is in use as > the design of smb signing assumes request response pairs whereas oplock > break notifications are asynchronous. Other than degenerate cases, > current Windows versions have been patched. Degenerate cases? This sounds like something only Microsoft could dream up, so I guess degenerate applies... ;) The whole idea is actually quite clever, but the problem is that it was idealised before people understood everything about networked file systems (the security aspect was completely overlooked at the beginning). The current versions are quite good, but as they have to be compatible with older clients (Win9X), a lot of hacks need to be done (not forgetting it was done in a time Microsoft didn't believe in the future of TCP/IP). For better or worse, is still the major network file system for small networks (and I don't see any future change on this). Regards, ~Nuno Lucas - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
Oplocks seems interesting. I will need to do some reading/testing. Thanks for all the comments and hints. /Daniel Jay Sprenkle wrote: I've heard this too. Windows networking has some issues with locking. You might research 'oplocks' or 'opportunistic locking' (or opportunistic caching) if you're interested in understanding what it's doing. I was reading it the other day and thought it might be the key to making it work correctly if you could turn oplocks off in windows. On 1/9/07, Daniel Önnerby <[EMAIL PROTECTED]> wrote: I thought I read somewhere in the docs that this was not reliable (maybe I dreamed it)??? This is great if this works, although I might still make the socketserver for notifying when updates has been made. Thank you for your replies. John Stanton wrote: > Why not just use the SMB file locks if you are using the SMB networking? -- The PixAddixImage Collector suite: http://groups-beta.google.com/group/pixaddix SqliteImporter and SqliteReplicator: Command line utilities for Sqlite http://www.reddawn.net/~jsprenkl/Sqlite Cthulhu Bucks! http://www.cthulhubucks.com - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
Oplocks do not break things. Oplocks will guarantee consistency. They are granted when only one client OS has a file open letting that client OS perform locking and caching operations internally without consulting the server each time. If another client wants to open the file, then that second open request is held up by the server, the first client contacted and asked to flush any outstanding data, acquire locks, and drop the oplock. Once that has happened then the second client gets the answer to its open request. How is the first client 'contacted' and asked to respond? I can't see how this is anything but useless. I can't imagine very many programs honor this kind of request since I've never even heard of this before last week. If the first client doesn't respond to the request it would have to degenerate to a standard lock. Is this an OS hack designed in for a specific microsoft application? There are other forms of oplocks that allow for opening and closing the file multiple times without consulting the server as well as some forms of limiting sharing (dropped when clients start using byte range locking). There have been some problems with Windows when smb signing is in use as the design of smb signing assumes request response pairs whereas oplock break notifications are asynchronous. Other than degenerate cases, current Windows versions have been patched. Degenerate cases? This sounds like something only Microsoft could dream up, so I guess degenerate applies... ;) - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Sprenkle wrote: > I've heard this too. Windows networking has some issues with locking. > You might research 'oplocks' or 'opportunistic locking' (or > opportunistic caching) > if you're interested in understanding what it's doing. I was reading > it the other > day and thought it might be the key to making it work correctly if you > could > turn oplocks off in windows. Oplocks do not break things. Oplocks will guarantee consistency. They are granted when only one client OS has a file open letting that client OS perform locking and caching operations internally without consulting the server each time. If another client wants to open the file, then that second open request is held up by the server, the first client contacted and asked to flush any outstanding data, acquire locks, and drop the oplock. Once that has happened then the second client gets the answer to its open request. There are other forms of oplocks that allow for opening and closing the file multiple times without consulting the server as well as some forms of limiting sharing (dropped when clients start using byte range locking). There have been some problems with Windows when smb signing is in use as the design of smb signing assumes request response pairs whereas oplock break notifications are asynchronous. Other than degenerate cases, current Windows versions have been patched. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpF+kmOOfHg372QQRAsUXAJ0WDnN/+L2EUO4Yp04eyo6XJU3a+QCg1Egd 81HnIn2KLf0QKyTlYsQIg3g= =DccF -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
I've heard this too. Windows networking has some issues with locking. You might research 'oplocks' or 'opportunistic locking' (or opportunistic caching) if you're interested in understanding what it's doing. I was reading it the other day and thought it might be the key to making it work correctly if you could turn oplocks off in windows. On 1/9/07, Daniel Önnerby <[EMAIL PROTECTED]> wrote: I thought I read somewhere in the docs that this was not reliable (maybe I dreamed it)??? This is great if this works, although I might still make the socketserver for notifying when updates has been made. Thank you for your replies. John Stanton wrote: > Why not just use the SMB file locks if you are using the SMB networking? -- The PixAddixImage Collector suite: http://groups-beta.google.com/group/pixaddix SqliteImporter and SqliteReplicator: Command line utilities for Sqlite http://www.reddawn.net/~jsprenkl/Sqlite Cthulhu Bucks! http://www.cthulhubucks.com - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
I thought I read somewhere in the docs that this was not reliable (maybe I dreamed it)??? This is great if this works, although I might still make the socketserver for notifying when updates has been made. Thank you for your replies. John Stanton wrote: Why not just use the SMB file locks if you are using the SMB networking? Daniel Önnerby wrote: Well.. I do not mean that I will use the socketserver to run queries against it. What I mean is that the database is opened by the applications from a windows share. The socketserver is only used to ask permission to write to the database and notifying the other applications that an update has been made. My thought was that this will not require much implementation on the application. Just adding a call to the socketserver before every INSERT or UPDATE, and that call will wait until the permission has been granted by the socketserver. Once the INSERT/UPDATE has been made, another call is made to the socketserver to unlock the database. The socketserver will then notify the other clients that an update has been made. Best regards Daniel John Stanton wrote: That should work quite well. We use such a strategy to implement remote, multi user access to Sqlite databases. the user is unconcerned about locking or contentions. In our case we made the server run on port 80 (HTTP) and use regular HTTP protocol so that it easily penetrates firewalls. The server in our case can either be a CGI process on a regular WWW server or use a purpose developed multi-threaded daemon which gives better performance. We make the data transport format XML for uniformity. For example if the usage requirement were to become too intensive for sqlite we can switch the shared database to being PostgreSQL without affecting the clients. Daniel Önnerby wrote: Hi all! At the company I work we have a windows application that use sqlite for the document format and this works great. We are now thinking about if it would be possible to have multiple users to access the db simultaneously from different computers (like a enterprise edition :) ). I have read everything about the multithreading issues and I know that sqlite is not designed to work like this. But I have an idea on how I might solve this in our case and would like to ask the community if you think this is a god idea (or if it would work at all): My idea is to create a small socketserver on the local network that the application holds an open connection to. When someone wants to write (lock) to the DB you always need to ask the socketserver if this is ok. The server will not keep any track of the database itself. The only purpose of the server is so that no one tries to write simultaneously. The server will also notify the applications when a modification has been made (on unlock). So.. could this work??? Best regards and thanks for the best (and smallest) SQL database ever made. Daniel - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
Why not just use the SMB file locks if you are using the SMB networking? Daniel Önnerby wrote: Well.. I do not mean that I will use the socketserver to run queries against it. What I mean is that the database is opened by the applications from a windows share. The socketserver is only used to ask permission to write to the database and notifying the other applications that an update has been made. My thought was that this will not require much implementation on the application. Just adding a call to the socketserver before every INSERT or UPDATE, and that call will wait until the permission has been granted by the socketserver. Once the INSERT/UPDATE has been made, another call is made to the socketserver to unlock the database. The socketserver will then notify the other clients that an update has been made. Best regards Daniel John Stanton wrote: That should work quite well. We use such a strategy to implement remote, multi user access to Sqlite databases. the user is unconcerned about locking or contentions. In our case we made the server run on port 80 (HTTP) and use regular HTTP protocol so that it easily penetrates firewalls. The server in our case can either be a CGI process on a regular WWW server or use a purpose developed multi-threaded daemon which gives better performance. We make the data transport format XML for uniformity. For example if the usage requirement were to become too intensive for sqlite we can switch the shared database to being PostgreSQL without affecting the clients. Daniel Önnerby wrote: Hi all! At the company I work we have a windows application that use sqlite for the document format and this works great. We are now thinking about if it would be possible to have multiple users to access the db simultaneously from different computers (like a enterprise edition :) ). I have read everything about the multithreading issues and I know that sqlite is not designed to work like this. But I have an idea on how I might solve this in our case and would like to ask the community if you think this is a god idea (or if it would work at all): My idea is to create a small socketserver on the local network that the application holds an open connection to. When someone wants to write (lock) to the DB you always need to ask the socketserver if this is ok. The server will not keep any track of the database itself. The only purpose of the server is so that no one tries to write simultaneously. The server will also notify the applications when a modification has been made (on unlock). So.. could this work??? Best regards and thanks for the best (and smallest) SQL database ever made. Daniel - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] multiuser DB on network share
Is it server available for the public or everybody has to find its own solution? We need to support access in home networks that usually consist of few PCs. Dusan -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 12:21 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] multiuser DB on network share That should work quite well. We use such a strategy to implement remote, multi user access to Sqlite databases. the user is unconcerned about locking or contentions. In our case we made the server run on port 80 (HTTP) and use regular HTTP protocol so that it easily penetrates firewalls. The server in our case can either be a CGI process on a regular WWW server or use a purpose developed multi-threaded daemon which gives better performance. We make the data transport format XML for uniformity. For example if the usage requirement were to become too intensive for sqlite we can switch the shared database to being PostgreSQL without affecting the clients. Daniel Önnerby wrote: > Hi all! > > At the company I work we have a windows application that use sqlite for > the document format and this works great. We are now thinking about if > it would be possible to have multiple users to access the db > simultaneously from different computers (like a enterprise edition :) ). > I have read everything about the multithreading issues and I know that > sqlite is not designed to work like this. But I have an idea on how I > might solve this in our case and would like to ask the community if you > think this is a god idea (or if it would work at all): > My idea is to create a small socketserver on the local network that the > application holds an open connection to. When someone wants to write > (lock) to the DB you always need to ask the socketserver if this is ok. > The server will not keep any track of the database itself. The only > purpose of the server is so that no one tries to write simultaneously. > The server will also notify the applications when a modification has > been made (on unlock). > > So.. could this work??? > > Best regards and thanks for the best (and smallest) SQL database ever made. > Daniel > > - > > To unsubscribe, send email to [EMAIL PROTECTED] > - > > - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] multiuser DB on network share
That should work quite well. We use such a strategy to implement remote, multi user access to Sqlite databases. the user is unconcerned about locking or contentions. In our case we made the server run on port 80 (HTTP) and use regular HTTP protocol so that it easily penetrates firewalls. The server in our case can either be a CGI process on a regular WWW server or use a purpose developed multi-threaded daemon which gives better performance. We make the data transport format XML for uniformity. For example if the usage requirement were to become too intensive for sqlite we can switch the shared database to being PostgreSQL without affecting the clients. Daniel Önnerby wrote: Hi all! At the company I work we have a windows application that use sqlite for the document format and this works great. We are now thinking about if it would be possible to have multiple users to access the db simultaneously from different computers (like a enterprise edition :) ). I have read everything about the multithreading issues and I know that sqlite is not designed to work like this. But I have an idea on how I might solve this in our case and would like to ask the community if you think this is a god idea (or if it would work at all): My idea is to create a small socketserver on the local network that the application holds an open connection to. When someone wants to write (lock) to the DB you always need to ask the socketserver if this is ok. The server will not keep any track of the database itself. The only purpose of the server is so that no one tries to write simultaneously. The server will also notify the applications when a modification has been made (on unlock). So.. could this work??? Best regards and thanks for the best (and smallest) SQL database ever made. Daniel - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
