jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: remove JackrabbitRepository.shutdown()
Date Wed, 16 Apr 2008 13:21:23 GMT

I think we agree that we disagree.

For Jukka Jackrabbit is a server, and the embedded use case (Model 1)
use case is completely unimportant. For me and Alexander, the embedded
use case (Model 1) is important. Not only because of performance, also
because of ease-of-use.

> Model 2 and 3 clients should not be able shutdown the repository,
> as the repository lifecycle is managed by the server.

Removing shutdown from the API will not solve this problem as
everybody can still call the method. A possible solution is that only
the very first session may call shutdown. Let's say there is
JackrabbitRepository.shutdown(Session adminSession). When the
repository is created the server (the entity that manages the
repository) opens a special 'admin session' and keeps it. An
application does not have access to it, only the server. If an
application calls shutdown with another session (or null) an exception
is thrown. The server can still force a shutdown if required. That's
just an idea and can still be improved.

> As a new Jackrabbit user these complicated ways to create and shutdown
> a repository are really annonying, because this is always the *first code*
> you will have to write to get it running in your application! So there should
> be lots of effort to make it as simple as possible!

I fully agree. I don't see how making things harder helps.

> And since all model 1 applications in any case have a direct
> Jackrabbit dependency, I don't see why we couldn't expect
> them to use the direct RepositoryImpl.shutdown() method.

Because RepositoryImpl is a class and not an interface. A) C) D) and
E). Again A-E for reference:
A) programming against interfaces
B) The "security" argument is invalid
C) How about Javadocs?
D) How about other implementations (RMI, CRX)?
E) JCRLog is impossible.

> Why not use TransientRepository?

That's probably the best solution so far. I'm not sure if that works
however. Some problems (which may be solvable):
- It cannot be used for remote repositories (can it?)
- The repository is closed (shut down) if the first login fails,
unlike other repositories
- It doesn't solve the Javadoc problem (the class has public methods
that should not be called)
- It's still a class not an interface
- No way to force shutdown (unlike with
JackrabbitSession.shutdown(Session adminSession))

> why would JCRLog need to cover shutdown?

You can't use JCRLog because ((RepositoryImpl)rep).shutdown() throws a
ClassCastException. Even if you could solve this somehow, another
problem remains. The JCRLog should log all method calls that affect
Jackrabbit. By re-playing the log file a repository should be in the
same state as before. If shutdown is not logged, you can't do that.
Example: an application could call shutdown too early or not at all.
Replaying the log file would result in another state, and you wouldn't
see the problem. The log file may contain multiple runs of an
application (multiple open-close / start-stop).

> It's probably more fruitful to debate that goal, as the way we expose
> the shutdown mechanism is highly dependent on the expected deployment
> model.

In my view Model 1 usage is important. Ease-of-use is important
(sample apps, Javadoc, wiki,...), and there are technical reasons why
shutdown should be part of an interface.

For me, Model 2 and 3 are variations of Model 1. In Model 1, the
client application starts and stops the repository, while in Model 2
and 3 the 'server' starts and stops it. There is even a Model 4: Mixed
Mode. In that case, the application starts the repository and uses it
in embedded mode, plus it starts a server so that other processes can
connect to it remotely. The main advantages of Model 4 are: high
performance for the embedded sessions, while providing remote access.
This model is what Alexander is proposing in "simple Repository start

> sling/jcrapp

This sounds like the 'server' model. My concern is that is internally
uses Jackrabbit specific classes directly. P.S. Maybe you want to
tweak the name a bit... Somehow it reminds me of Crap4J
(http://www.crap4j.org/). Sorry, just joking.


View raw message