Bruji

Conor, you wrote a few months ago:

The information is updated for an entry when the other DVDpedia goes to save an entry (it merges any changes together). For performance it does not go to disk if the data is already in memory. We did think about this and have it as feature request to add some kind of advance setting to set a time out limit for the data in memory so that changes by another computer are seen in a running version.

We're using Bookpedia in a multi-user borrowing environment. We followed the instructions for sharing a library, but had a few minutes of head-scratching this morning before we realized why changes weren't visible on other systems. If changes could be written without quitting (whether at the time that a change is made or at a regular interval), not only would that make Bookpedia viable for sharing, but it would also prevent data loss in the case of a sudden system shutdown.

Have you decided if this is a feature that you'll be adding to the pedias?

We only started to explored the possibilities in that area. It's turning out to involve a lot of work to get the programs to show the information immediately. The program always saves changes, so there is no danger of data loss. What is happening is Bookpedia does a lot of caching of the information (to stay speedy), so the the second Bookpedia (where the changes were not made), does not see the changes. However it will merge information when it realizes a change has taken place. Change the title of a book in one Bookpedia and then open the same book for edit and close it on the other Bookpedia and you will see the information refresh. So it is possible to work simultaneously on two Bookpedias. I will continue to explore what is possible and find out if there is a good technical solution. Thank you for the feedback.

Interesting -- so it's a problem of reading, not of writing. I'd assumed that writes, being expensive, would be the end of things that would be cached, rather than reads. But since most libraries' metadata is surely small enough to keep within memory, it really does make sense to do that. Writing on a schedule is logical (if one is caching the writes and then periodically recording them), but reading on a schedule would seem to present an obstacle in a multi-user environment. (Not least of which the very problem that I've complained about here.)

The particularly puzzling problem that we've had here is that a new book is entered on one system (our book review editor's), but it's not visible on another system (our public terminal) until Bookpedia is quit and restarted. If I'm properly understanding what you're explaining, there's no workaround for that now -- we'll just know that we have to restart Bookpedia on that terminal periodically if we want to display the most recently added books. Is that correct?

Writing is expensive, but the user data is more important to us; so writes are done after every change. Also now using SQL only the data that needs updating is written out, so it's much less expensive than our previous XML database. With reading on a schedule the problem, as you summarized it, is that without Bookpedia knowing what has changed it would need to reload the entire file to update. Just as SQL provides the ability to do partial writes it also allows for partial reading. The elegant solution is for the Bookpedias to communicate with each other and inform each other what entries are new or have been updated. Implementing a communication over a network is not trivial but more importantly both solutions would introduce a concurrency issue that adds enormous complexity; you would have to make sure that a reload of the data does not happen as another important operation is taking place simultaneously and that is why this feature is on the to do list. So a restart of Bookpedia would be needed to reflect the changes by other machines.