[
https://issues.apache.org/jira/browse/JENA-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025192#comment-14025192
]
ASF subversion and git services commented on JENA-648:
------------------------------------------------------
Commit 1601380 from [~rvesse] in branch 'jena/trunk'
[ https://svn.apache.org/r1601380 ]
Initial impl of lock files to help protect TDB datasets from corruption due to
multi-JVM usage (JENA-648)
> Make TDB datasets harder to corrupt
> -----------------------------------
>
> Key: JENA-648
> URL: https://issues.apache.org/jira/browse/JENA-648
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Attachments: JENA-648-lock-files.patch
>
>
> This RFE comes out of discussions I had in person with Andy earlier this
> week. On the mailing lists and Q&A sites we see a steady stream of questions
> from people who have corrupted TDB databases and it would be nice if we could
> put in place features that make this harder to do.
> There are two main things we should do in the long term as I see it:
> # Make using TDB non-transactonally more difficult
> # Put in place some mechanism to make it difficult for multiple JVMs to
> access the same TDB dataset simultaneously
> Me and Andy think the first could be achieved by making TDB datasets
> operation in auto-commit more rather than non-transactional mode by default.
> In order to allow this we likely need upgradeable read transactions to be
> supported. As part of this change non-transactional mode would still be
> supported but users would have to explicitly set some "Here be Dragons" style
> flag in order to do this. Users who aren't using transactions currently
> would likely merely see performance drop since suddenly they are getting
> auto-commits on every operation but when they complain we can tell them they
> should be using transactions properly to ensure their TDB databases remain
> uncorrupted.
> As far as the second point goes we could likely do this the way a lot of
> other applications do by having the code write a lock file to disk when a
> database is opened which contains the owning processes PID. Whenever you go
> to open a database the presence of the lock file is checked for and if
> present the PID validated with the code refusing to open the database if the
> PIDs do not match. There would likely need to be some code to cope with the
> case where the lock file gets left around and the owning PID is not alive but
> that shouldn't be too complicated.
> Since these may be considered as substantial behavioural changes to TDB these
> may likely go into Jena 3
--
This message was sent by Atlassian JIRA
(v6.2#6252)
