incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paolo Castagna (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-214) Allow to set Fuseki (or a single dataset) in read-only mode (and eventually, back into read-write mode)
Date Thu, 23 Feb 2012 10:31:48 GMT


Paolo Castagna commented on JENA-214:

> Not for readWriteGraphStoreEP as it is both read and write operations.

Yep. Good point.

> Can holders be restarted?

There is an holder.start() method as well, so I suppose so. 
I have never used/done it before, so I am not 100% sure it is a safe/good thing to do.

> Won't programming based on the lifecycle will make it Jetty specific? - see also JENA-201
which is asking for Fuseki as a (portable) WAR file. 

Right, good point... back to thinking mode... I'll look if there a generic way given a path
/{dataset}/{service} to find the servlet instance dealing with those requests. If that is
possible, we could have a flag to switch between read-write to read-only mode on the necessary
> Allow to set Fuseki (or a single dataset) in read-only mode (and eventually, back into
read-write mode)
> -------------------------------------------------------------------------------------------------------
>                 Key: JENA-214
>                 URL:
>             Project: Apache Jena
>          Issue Type: New Feature
>          Components: Fuseki
>            Reporter: Paolo Castagna
>            Priority: Minor
>         Attachments:
> A very useful MgtCmdServlet with commands such as: "backup", "shutdown", etc. is now
available in Fuseki.
> This is proposing a new command to set the server (or a single dataset) in read-only
mode and back into read-write mode.
> A use case for this would be to perform a replication via rsync, in order to replicate
TDB indexes from server A to server B both servers needs to be set to read-only mode first,
the replication can start, when it finishes both servers can be configured back to read-write
> Another use case would be, enabling a backup with an external tool or any other operation
which needs to have exclusive access to TDB indexes and/or ensure all data has been flushed
to disk and there are no in-flight write transactions.
> See also a relevant message from jena-dev mailing list:
>  -

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message