Quote:
Originally Posted by coleman
A commoin approach for simultaneous access these days would be to move up to a multiuser RDBMS (i.e. SQL Server, Oracle, PostGRESQL..the list goes on), and possibly adding in some sort of message queuing (MSMQ, or Service Bus in Azure, for instance). The queuing services might be some of what you are referring to as a transaction monitor, but full-blown multi-user databases fundamentally support transaction concurrency and consistency. It's non-trivial work+infrastructure to add those things though. Well, switching to a full blown database would probably be not too bad, but there's no real reason to.
The problems I'm considering probably haven't even crossed most Calibre user's minds, and wouldn't be an issue for me even if I wasn't using Calibre-web for the web piece. Honestly, the chances are that it would even be a problem for me are slim, I'm just over-cautious having lived through developing apps way back in the day backed by Access databases.
|
'Requests' to be able to run two or more instances of calibre.exe, calibre-server, calibredb.exe, and 3rd party programs against the same set of libraries are quite frequent - maybe one a week. And a common cause of things going haywire is when users don't heed the warnings in the FAQ section of the manual.
Not a fan of shoehorning everything into an RDBMS (-ve experience with Sybase and SQLServer), I grew up on Bachman databases and Univac TIPS and GE whatever it was**. So, I have a bit of an anti-Codd bias.
As you say it's a non-trivial issue, hoped a silver bullet might have eventuated when i wasn't looking
Added: ** It was TDS (Transaction Driven Subsystem) - pronounced TeDiouS.
BR