You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2005/10/06 13:07:52 UTC
[jira] Created: (JCR-245) Automatic repository shutdown
Automatic repository shutdown
-----------------------------
Key: JCR-245
URL: http://issues.apache.org/jira/browse/JCR-245
Project: Jackrabbit
Type: New Feature
Components: core
Reporter: Jukka Zitting
Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
1) client application invoking RepositoryImpl.shutdown(), or
2) the shutdown hook installed by RepositoryImpl being run
Both of these mechanisms have problems:
1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-245) Automatic repository shutdown
Posted by "Günther Humer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=comments#action_12359400 ]
Günther Humer commented on JCR-245:
-----------------------------------
What about sth. like implementing the Repository as a Singleton?
But not in the common term of singleton, more like one instance for each Repository-Home directory.
RepositoryImpl.getRepository(homeDir1) provides the same instance as.
RepositoryImpl.getRepository(homeDir1)
But
RepositoryImpl.getRepository(homeDir2) provides a new instance.
The repository is still shutdown, with the shutdown hook and initialized, when the user creates a Session or gets the Repository.
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-245) Automatic repository shutdown
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=all ]
Jukka Zitting resolved JCR-245:
-------------------------------
Fix Version: 1.0
Resolution: Fixed
Committed the proposed TransientRepository class in revision 355430 with the following changes:
* Added a simple TransientRepository.RepositoryFactory interface to allow greater control over the repository initialization process
* Added a two utility constructors
* Added an initial test case for the TransientRepository class (more complete unit testing would require a separate test repository or setting up mock RepositoryImpl instances)
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.0
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (JCR-245) Automatic repository shutdown
Posted by Alexandru Popescu <th...@gmail.com>.
Looks interesting Jukka. I will take a deeper look.
./alex
--
.w( the_mindstorm )p.
#: Jukka Zitting (JIRA) changed the world a bit at a time by saying on 12/7/2005 1:39 AM :#
> [ http://issues.apache.org/jira/browse/JCR-245?page=all ]
>
> Jukka Zitting updated JCR-245:
> ------------------------------
>
> Attachment: TransientRepository.patch
>
> The attached patch contains org.apache.jackrabbit.core.TransientRepository, a proxy repository class that automatically initializes and shuts down the underlying RepositoryImpl instance when sessions are opened or closed. I implemented this as a separate class to avoid overloading the already heavy RepositoryImpl class. The implementation is quite clean except for two things: 1) it loads the default repository descriptors directly from repository.properties, and 2) it messes with RepositoryImpl.loggedOut(SessionImpl) to avoid a nasty infinite loop in RepositoryImpl.shutdown().
>
> The class is quite easy to use and works very well with component containers like Spring where setting up an explicit shutdown call is difficult and cumbersome. If it weren't for the repository initialization and shutdown overhead, it would also make a fine candidate for solving the deployment model 2 shutdown issues discussed lately on the mailing list. The implementation also relies on all clients properly closing all the sessions they've opened. If needed, the implementation could be modified to use a WeakHashMap to cope with lost sessions.
>
> Example code:
>
> RepositoryConfig config = RepositoryConfig.create("...", "...");
> Repository repository = new TransientRepository(config);
> Session session = repository.login(); // Repository gets initialized
> try {
> // Use the session
> } finally {
> session.logout(); // Repository gets shut down
> }
>
> Any problems with this approach that I haven't noticed? I've been quite happy using a class like this in my Spring-based projects, so unless anyone objects I'll go ahead and commit it so others can use it too.
>
>
>> Automatic repository shutdown
>> -----------------------------
>>
>> Key: JCR-245
>> URL: http://issues.apache.org/jira/browse/JCR-245
>> Project: Jackrabbit
>> Type: New Feature
>> Components: core
>> Reporter: Jukka Zitting
>> Attachments: TransientRepository.patch
>>
>> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
>> 1) client application invoking RepositoryImpl.shutdown(), or
>> 2) the shutdown hook installed by RepositoryImpl being run
>> Both of these mechanisms have problems:
>> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
>> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
>> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
>> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
>> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
>
[jira] Updated: (JCR-245) Automatic repository shutdown
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=all ]
Jukka Zitting updated JCR-245:
------------------------------
Attachment: TransientRepository.patch
The attached patch contains org.apache.jackrabbit.core.TransientRepository, a proxy repository class that automatically initializes and shuts down the underlying RepositoryImpl instance when sessions are opened or closed. I implemented this as a separate class to avoid overloading the already heavy RepositoryImpl class. The implementation is quite clean except for two things: 1) it loads the default repository descriptors directly from repository.properties, and 2) it messes with RepositoryImpl.loggedOut(SessionImpl) to avoid a nasty infinite loop in RepositoryImpl.shutdown().
The class is quite easy to use and works very well with component containers like Spring where setting up an explicit shutdown call is difficult and cumbersome. If it weren't for the repository initialization and shutdown overhead, it would also make a fine candidate for solving the deployment model 2 shutdown issues discussed lately on the mailing list. The implementation also relies on all clients properly closing all the sessions they've opened. If needed, the implementation could be modified to use a WeakHashMap to cope with lost sessions.
Example code:
RepositoryConfig config = RepositoryConfig.create("...", "...");
Repository repository = new TransientRepository(config);
Session session = repository.login(); // Repository gets initialized
try {
// Use the session
} finally {
session.logout(); // Repository gets shut down
}
Any problems with this approach that I haven't noticed? I've been quite happy using a class like this in my Spring-based projects, so unless anyone objects I'll go ahead and commit it so others can use it too.
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-245) Automatic repository shutdown
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=all ]
Jukka Zitting closed JCR-245:
-----------------------------
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.0
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-245) Automatic repository shutdown
Posted by "Alexandru Popescu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=comments#action_12359405 ]
Alexandru Popescu commented on JCR-245:
---------------------------------------
The solution with singletons is still problematic considering the classloaders.
./alex
--
.w( the_mindstorm )p.
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-245) Automatic repository shutdown
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=all ]
Jukka Zitting reassigned JCR-245:
---------------------------------
Assign To: Jukka Zitting
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-245) Automatic repository shutdown
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=comments#action_12359500 ]
Jukka Zitting commented on JCR-245:
-----------------------------------
Günther Humer asked:
> What about sth. like implementing the Repository as a Singleton?
I think that's a solution looking for a problem. It's a different issue than the one raised here, and besides I think that guarding against duplicate repository configuration is better done at the application or container level. See also http://c2.com/cgi/wiki?SingletonGlobalProblems
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-245) Automatic repository shutdown
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-245?page=comments#action_12359563 ]
Stefan Guggisberg commented on JCR-245:
---------------------------------------
jukka's patch:
> Any problems with this approach that I haven't noticed? I've been quite happy using a class
> like this in my Spring-based projects, so unless anyone objects I'll go ahead and commit it
> so others can use it too.
+1
i think that TransientRepository is a very useful alternative for certain use-cases.
> Automatic repository shutdown
> -----------------------------
>
> Key: JCR-245
> URL: http://issues.apache.org/jira/browse/JCR-245
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Jukka Zitting
> Attachments: TransientRepository.patch
>
> Currently Jackrabbit relies on two mechanisms for safely shutting down a repository:
> 1) client application invoking RepositoryImpl.shutdown(), or
> 2) the shutdown hook installed by RepositoryImpl being run
> Both of these mechanisms have problems:
> 1) The shutdown() method is not a part of the JCR API, thus making the client application depend on a Jackrabbit-specific feature
> 2) In some cases the shutdown hook is not properly run (see issues JCR-120 and JCR-233)
> I think the JCR spec thinks of the Repository and Session interfaces as being somewhat similar to the JDBC DataSource and Connection interfaces. The Repository instances have no real lifecycle methods while the Session instances have clearly specified login and logout steps. (DataSource.getConnection() = Repository.login(), Session.logout() = Connection.close()) However the Jackrabbit implementation defines an explicit lifecycle for the RepositoryImpl instances.
> This causes problems especially for container environments (JNDI, Spring) where it is hard or even impossible to specify a shutdown mechanism for resource factories like the Repository instances. The current solution for such environments is to use a shutdown hook, but as reported this solution does not work perfectly in all cases.
> How about if we bound the RepositoryImpl lifecycle to the lifecycles of the instantiated Sessions. A RepositoryImpl instance could initialize (and lock) the repository when the first session is opened and automatically shut down when the last session has logged out. As long as the sessions are properly logged out (or finalized by the garbage collector) there would be no need for an explicitly RepositoryImpl.shutdown() call. The current behaviour of pre-initializing the repository and shutting down during a shutdown hook could be enabled with a configuration option for environments (like global JNDI resources) in which the shutdown hooks work well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira