jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Toper" <nto...@gmail.com>
Subject Re: Client/Server question
Date Wed, 31 May 2006 14:42:21 GMT
Actually, Jukka and I decided to add the hotbackup fonctionnality in a next
step. I will design the tool so this can be added easily later on.

We want to create a tool "battle tested" and we fear adding a proxyPM might
spread our effort and add too much testing cases for a first step (with
probable appearances of transient and intermittent bugs). Please keep in
mind, it is the first time, I am working with JackRabbit.

See past Jukka mail:
"This is something that we should look at later on. Modifying the
internal persistence data path is quite risky in terms of possible new
bugs and regressions so I'd rather not extend the scope of the SoC
project to cover that. I'd be happy with just a global write lock that
guarantees data consistency in the repository. For the SoC project I'd
even be OK with a tool that simply relies on the administrator to
enforce a no-write policy during backup. It's still better than we
have now and we can extend and improve the solution later on."

I will probably add hotbackup on one form or another after the Google SoC.

BR,
Nicolas
my blog! http://www.deviant-abstraction.net !!
On 5/31/06, David Kennedy < davek@us.ibm.com> wrote:
>
> What happened to the idea of backing up to a PesistenceManager and
> restoing from one as well?  As long as you add an interface and the
> PersistenceManager implements the backup/restore interface, it's still
> feasible, but was there a problem with this strategy?
>
> David
>
> "Nicolas Toper" <ntoper@gmail.com> wrote on 05/31/2006 08:51:31 AM:
>
> > Hi Felix,
> >
> > You are right on both points. I will do as you suggest.
> >
> > Thanks for your input.
> >
> > Best Regards
> > Nico
> > my blog! http://www.deviant-abstraction.net !!
> >
> > On 5/31/06, Felix Meschberger < fmeschbe@gmail.com> wrote:
> > >
> > > Hi Nicolas,
> > >
> > > I agree to include these methods on the repository layer. But thinking
>
> > > about the extent - rather than the intrincacies of handling concurrent
>
> > > modifications while backing up - I would have some remarks:
> > >
> > > (1) I would modify the signature to take InputStream and OutputStream
> > > objects, resp. This provides for more flexibility in terms of source
> > > and destination of the backup data.
> > >
> > > (2) Initially you mentioned a configuration file for the
> > > backup/restore procedures. I suggest you define configuration classes
> > > (interfaces), which can load/store themselves to and from streams
> > > (yes, I do not like being locked into File instances :-) and to add
> > > instances of the toplevel configuration (e.g. BackupConfiguration) as
> > > a parameter to the backup/restore methods.
> > >
> > > These two changes would greatly improve the flexibility using the API
> > > from within an application as opposed to from the command line. Also
> > > testing would be greatly simplified, I suppose.
> > >
> > > Regards
> > > Felix
> > >
> > >
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message