Re: Connection pooling
hi matej
On Tue, Jul 22, 2008 at 1:39 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The idea of Jackrabbit managing DataSources didn't gain much support,
> so I decided to try implementing something much less intrusive. I have
> abstracted connection creation/closing (ConnectionProvider[1]) from
> the components that use database connections. There is one instance of
> ConnectionProvider per repository, configurable in repository.xml, but
> possibly with a sane default implementation so no configuration is
> necessary.
>
> The rest of jackrabbit (components that touch the database) would use
> ConnectionProvider to get the connections instead of just creating
> them and keeping opened. So far I've converted
> BundleDbPersistenceManager (and it's subclasses) to this approach. I
> would also tweak DatabasePersistenceManager and DbFileSystem to just
> borrow the connections instead of keeping them. As for journal,
> keeping one opened connection per repository probably doesn't make
> much difference.
>
> The benefit of this approach is that there is zero change in
> repository configuration, unless user wants to specify it's own
> ConnectionProvider class, which can be specified as a simple bean with
> element name ConnectionProvider.
>
> ConnectionProvider implementation that supports pooling must take
> different things into account, such as there can be request to various
> connections from different databases with different URLs. The manager
> must be intelligent enough to possibly maintain group of pools (e..g
> per database or even per connection URL)
>
> There is a SimplePoolingConnectionProvider implementation included in
> the patch that implements connection pooling, but it's only meant as
> proof of concept and doesn't try to substitute "real" connection
> pooling alternatives (dbcp, etc.)
>
> I've attached the first patch to
> https://issues.apache.org/jira/browse/JCR-1456
thanks for the patch. i added my comments on the jira issue.
cheers
stefan
>
> Kind regards,
> -Matej
>
> [1] ConnectionProvider class
>
> /**
> * Class responsible for providing SQL [EMAIL PROTECTED] Connection}s.
> *
> * Implementation of this class can do connection pooling, in which case it
> must
> * take [EMAIL PROTECTED] ConnectionProperties} into account and only return
> connection
> * that matches the specified properties.
> */
> public interface ConnectionProvider {
>
>/**
> * Returns connection with given properties.
> *
> * @param properties
> *connection properties
> * @return SQL [EMAIL PROTECTED] Connection}
> *
> * @throws RepositoryException
> * @throws SQLException
> */
>public Connection getConnection(ConnectionProperties properties)
>throws RepositoryException, SQLException;
>
>/**
> * Closes the given connection. Classes that obtain connections through
> * [EMAIL PROTECTED] ConnectionProvider} must never call [EMAIL PROTECTED]
> Connection#close()}
> * directly. They are required to call [EMAIL PROTECTED]
> #closeConnection(Connection)}
> * instead.
> *
> * @param connection
> *SQL [EMAIL PROTECTED] Connection}
> *
> * @throws SQLException
> */
>public void closeConnection(Connection connection) throws SQLException;
>
>/**
> * Invoked when the repository is being shut down.
> *
> * @throws RepositoryException
> */
>public void dispose() throws RepositoryException;
>
>/**
> * Bean that holds properties necessary to create or identify a SQL
> * [EMAIL PROTECTED] Connection}.
> */
>public final static class ConnectionProperties {
>private String user;
>private String password;
>private String url;
>private String driver;
>
>public String getUser() {
>return user;
>}
>
>public void setUser(String user) {
>this.user = user;
>}
>
>public String getPassword() {
>return password;
>}
>
>public void setPassword(String password) {
>this.password = password;
>}
>
>public String getUrl() {
>return url;
>}
>
>public void setUrl(String url) {
>this.url = url;
>}
>
>public void setDriver(String driver) {
>this.driver = driver;
>}
>
>public String getDriver() {
>return driver;
>}
>
>private boolean equals(String s1, String s2) {
>return s1 == s2 || (s1 != null && s1.equals(s2));
>}
>
>public boolean equals(Object obj) {
>if (this == obj) {
>return true;
>}
>if (obj instanceof ConnectionProperties == false) {
>return false;
>}
>ConnectionProperties cp = (ConnectionProperties) obj;
>return equals(user, cp.user) && equals(password, cp.password)
Re: Connection pooling
Hi,
The idea of Jackrabbit managing DataSources didn't gain much support,
so I decided to try implementing something much less intrusive. I have
abstracted connection creation/closing (ConnectionProvider[1]) from
the components that use database connections. There is one instance of
ConnectionProvider per repository, configurable in repository.xml, but
possibly with a sane default implementation so no configuration is
necessary.
The rest of jackrabbit (components that touch the database) would use
ConnectionProvider to get the connections instead of just creating
them and keeping opened. So far I've converted
BundleDbPersistenceManager (and it's subclasses) to this approach. I
would also tweak DatabasePersistenceManager and DbFileSystem to just
borrow the connections instead of keeping them. As for journal,
keeping one opened connection per repository probably doesn't make
much difference.
The benefit of this approach is that there is zero change in
repository configuration, unless user wants to specify it's own
ConnectionProvider class, which can be specified as a simple bean with
element name ConnectionProvider.
ConnectionProvider implementation that supports pooling must take
different things into account, such as there can be request to various
connections from different databases with different URLs. The manager
must be intelligent enough to possibly maintain group of pools (e..g
per database or even per connection URL)
There is a SimplePoolingConnectionProvider implementation included in
the patch that implements connection pooling, but it's only meant as
proof of concept and doesn't try to substitute "real" connection
pooling alternatives (dbcp, etc.)
I've attached the first patch to https://issues.apache.org/jira/browse/JCR-1456
Kind regards,
-Matej
[1] ConnectionProvider class
/**
* Class responsible for providing SQL [EMAIL PROTECTED] Connection}s.
*
* Implementation of this class can do connection pooling, in which case it must
* take [EMAIL PROTECTED] ConnectionProperties} into account and only return
connection
* that matches the specified properties.
*/
public interface ConnectionProvider {
/**
* Returns connection with given properties.
*
* @param properties
*connection properties
* @return SQL [EMAIL PROTECTED] Connection}
*
* @throws RepositoryException
* @throws SQLException
*/
public Connection getConnection(ConnectionProperties properties)
throws RepositoryException, SQLException;
/**
* Closes the given connection. Classes that obtain connections through
* [EMAIL PROTECTED] ConnectionProvider} must never call [EMAIL PROTECTED]
Connection#close()}
* directly. They are required to call [EMAIL PROTECTED]
#closeConnection(Connection)}
* instead.
*
* @param connection
*SQL [EMAIL PROTECTED] Connection}
*
* @throws SQLException
*/
public void closeConnection(Connection connection) throws SQLException;
/**
* Invoked when the repository is being shut down.
*
* @throws RepositoryException
*/
public void dispose() throws RepositoryException;
/**
* Bean that holds properties necessary to create or identify a SQL
* [EMAIL PROTECTED] Connection}.
*/
public final static class ConnectionProperties {
private String user;
private String password;
private String url;
private String driver;
public String getUser() {
return user;
}
public void setUser(String user) {
this.user = user;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public String getUrl() {
return url;
}
public void setUrl(String url) {
this.url = url;
}
public void setDriver(String driver) {
this.driver = driver;
}
public String getDriver() {
return driver;
}
private boolean equals(String s1, String s2) {
return s1 == s2 || (s1 != null && s1.equals(s2));
}
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj instanceof ConnectionProperties == false) {
return false;
}
ConnectionProperties cp = (ConnectionProperties) obj;
return equals(user, cp.user) && equals(password, cp.password)
&& equals(url, cp.url) && equals(driver, cp.driver);
}
private int hashCode(String s) {
return s != null ? s.hashCode() : 0;
}
public int hashCode() {
return hashCode(user) + 37 * hashCode(password) + 373
& hashCode(url) + 1187 * hashCode(driver);
Re: Connection pooling
On Thu, Jul 17, 2008 at 9:09 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > On Thu, Jul 17, 2008 at 6:47 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I am trying to understand both Matej and Alexander / Marcel... >> >> In my view Jackrabbit should be able to obtain database connections >> using a JDBC URL as well as a data source name. If Jackrabbit requires >> some kind of connection pooling, that should be integrated in >> Jackrabbit - otherwise it is not possible to use Jackrabbit in a >> standalone application. Otherwise FirstHop couldn't be started from >> the command line. > > What should such integration look like? Would you allow the user to > chose the connection pooling implementation or would you "hardcode" > one? What if user already has connection pooling infrastructure in > place (but not one exported by JNDI)? > > I still don't quite understand what is the big issue with managing > DataSource instances. We are not talking about writing an IoC > container here. All that would do is a simple map -> > where dataSourceInstance is a simple java bean > implementing DataSource. > > If user wants jndi, the bean would be simple JNDI DataSource proxy. > C3P0 or commons-dbcp have their own data source classes already that > could be easily configured. Or user could provide a DataSource that > would proxy calls to a spring/guice/hivemind managed beans. > > All of those would be trivial to write and configure. > > One of the annoyances with jackrabbit apart from the fact that it > keeps db connections opened is that it only provides two options to > obtain the actual connections. Either through JNDI or it creates the > connections on it's own. But there is a good reason why the DataSource > interface was introduced. I really don't think it is a good idea to > have Jackrabbit creating database connections without having a simple > way to override this behavior. DataSource et al are fine for client/user applications. jackrabbit OTOH is an infrastructure app and therefore needs exclusive control over the persistence layer (i.e. jdbc connections in this case). with hindsight i regret i did implement the jdbc persistence manager in the first place (it was meant as a proof of concept only). but that's a different story and just my very personal view ;) cheers stefan > > -Matej >
Re: Connection pooling
On Thu, Jul 17, 2008 at 6:47 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to understand both Matej and Alexander / Marcel... > > In my view Jackrabbit should be able to obtain database connections > using a JDBC URL as well as a data source name. If Jackrabbit requires > some kind of connection pooling, that should be integrated in > Jackrabbit - otherwise it is not possible to use Jackrabbit in a > standalone application. Otherwise FirstHop couldn't be started from > the command line. What should such integration look like? Would you allow the user to chose the connection pooling implementation or would you "hardcode" one? What if user already has connection pooling infrastructure in place (but not one exported by JNDI)? I still don't quite understand what is the big issue with managing DataSource instances. We are not talking about writing an IoC container here. All that would do is a simple map -> where dataSourceInstance is a simple java bean implementing DataSource. If user wants jndi, the bean would be simple JNDI DataSource proxy. C3P0 or commons-dbcp have their own data source classes already that could be easily configured. Or user could provide a DataSource that would proxy calls to a spring/guice/hivemind managed beans. All of those would be trivial to write and configure. One of the annoyances with jackrabbit apart from the fact that it keeps db connections opened is that it only provides two options to obtain the actual connections. Either through JNDI or it creates the connections on it's own. But there is a good reason why the DataSource interface was introduced. I really don't think it is a good idea to have Jackrabbit creating database connections without having a simple way to override this behavior. -Matej
Re: Connection pooling
What if you want to use C3P0 or commons dbcp or anything else for that matter but you don't want to obtain it through JNDI because you use spring/guice/hivemind or any other IoC container? Or what if you don't use a IoC container at all, nor you deploy to an application server but you still want to have connection pooling. How do you deal with that? -Matej On Thu, Jul 17, 2008 at 8:26 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > I think there is a misunderstanding. It is already possible to use > data sources in Jackrabbit as described here: > > http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ > "As of Jackrabbit 1.4, the connection can be created using a JNDI Data > Source as well. To do that, the driver class name must reference a > javax.naming.Context class (for example javax.naming.InitialContext), > and the URL must be the JNDI URL (for example > java:comp/env/jdbc/Test)." > > I think this paragraph is hidden too much, I will add a title to it > and add it to the FAQ as well. > >>> If you get database connection pooling in Jackrabbit without >>> DataSources (using the aforementioned commons-dbcp for example), why >>> do you need a explicit DataSource configuration inside the >>> repository.xml then? > > I agree, if possible the data source configuration shouldn't be > included in the repository.xml if not needed. And I don't see why it > would be needed to use data sources. > > Regards, > Thomas >
Re: Connection pooling
Hi, I think there is a misunderstanding. It is already possible to use data sources in Jackrabbit as described here: http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ "As of Jackrabbit 1.4, the connection can be created using a JNDI Data Source as well. To do that, the driver class name must reference a javax.naming.Context class (for example javax.naming.InitialContext), and the URL must be the JNDI URL (for example java:comp/env/jdbc/Test)." I think this paragraph is hidden too much, I will add a title to it and add it to the FAQ as well. >> If you get database connection pooling in Jackrabbit without >> DataSources (using the aforementioned commons-dbcp for example), why >> do you need a explicit DataSource configuration inside the >> repository.xml then? I agree, if possible the data source configuration shouldn't be included in the repository.xml if not needed. And I don't see why it would be needed to use data sources. Regards, Thomas
Re: Connection pooling
> > If you get database connection pooling in Jackrabbit without > DataSources (using the aforementioned commons-dbcp for example), why > do you need a explicit DataSource configuration inside the > repository.xml then? > I don't really understand the question. What exactly do you mean by " database connection pooling in Jackrabbit without DataSources"? DataSource is just an interface to isolate jackrabbit from the details of who and how is providing database connection. Jackrabbit doesn't need to know how exactly the data source obtains the connection, or if it is from a pool or not. The whole idea is to make jackrabbit agnostic of source of the connection while allowing easy configuration for scenarios when jackabbit actually is responsible for managing the database connections (embedded databases). -Matej > Regards, > Alex > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
Re: Connection pooling
On Thu, Jul 17, 2008 at 7:07 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Well, > > i think the easiest solution would be if jackrabbit instantiated and > maintained DataSource instances. This gives the most flexibility. > > If someone wants to get a data source from JNDI it would be only > matter of using the right (proxied) data source. > > > > > > or you can have datasource from the connection pool, e.g. > > > > > > > Just because jackrabbit would manage the data sources it doesn't mean > it should do the pooling, etc. The DataSources it instantiates could > be just simple proxies to JNDI, spring, or whatever else that would > manage the datasources. > > This way jackrabbit could leverage container data source management > without having any direct dependencies that would prevent it from > running standalone. If you get database connection pooling in Jackrabbit without DataSources (using the aforementioned commons-dbcp for example), why do you need a explicit DataSource configuration inside the repository.xml then? Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Connection pooling
Well, i think the easiest solution would be if jackrabbit instantiated and maintained DataSource instances. This gives the most flexibility. If someone wants to get a data source from JNDI it would be only matter of using the right (proxied) data source. or you can have datasource from the connection pool, e.g. Just because jackrabbit would manage the data sources it doesn't mean it should do the pooling, etc. The DataSources it instantiates could be just simple proxies to JNDI, spring, or whatever else that would manage the datasources. This way jackrabbit could leverage container data source management without having any direct dependencies that would prevent it from running standalone. -Matej On Thu, Jul 17, 2008 at 6:47 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to understand both Matej and Alexander / Marcel... > > In my view Jackrabbit should be able to obtain database connections > using a JDBC URL as well as a data source name. If Jackrabbit requires > some kind of connection pooling, that should be integrated in > Jackrabbit - otherwise it is not possible to use Jackrabbit in a > standalone application. Otherwise FirstHop couldn't be started from > the command line. > > It's not required to explicitly declare data sources in > repository.xml, and I believe it should not be declared because it is > added complexity for the user of Jackrabbit. Connection pooling can be > implemented in another way, for example as it is done in the > DbDataStore now, or using commons-dbcp. Maybe there is even a simpler > solution, I don't know yet. I guess we should try to find a better > solution for this problem. > > Regards, > Thomas >
Re: Connection pooling
Hi, I am trying to understand both Matej and Alexander / Marcel... In my view Jackrabbit should be able to obtain database connections using a JDBC URL as well as a data source name. If Jackrabbit requires some kind of connection pooling, that should be integrated in Jackrabbit - otherwise it is not possible to use Jackrabbit in a standalone application. Otherwise FirstHop couldn't be started from the command line. It's not required to explicitly declare data sources in repository.xml, and I believe it should not be declared because it is added complexity for the user of Jackrabbit. Connection pooling can be implemented in another way, for example as it is done in the DbDataStore now, or using commons-dbcp. Maybe there is even a simpler solution, I don't know yet. I guess we should try to find a better solution for this problem. Regards, Thomas
Re: Connection pooling
This assumes that you are running jackrabbit in environment that manages DataSources. I think that's a bit far fetched assumptions. So far I didn't notice jackrabbit having any dependencies on the environment you are running it within. And I'm also not really sure about the servlet engine being responsible for DataSource management. I think the roles are orthogonal. Some servlet containers manage data sources, some don't (jetty). I don't think it is a good idea to rely on the servlet container to manage the data source. Doing it this way it would be no longer possible to configure the database connection from repository.xml. Also it could get complicated for persistence managers that use different database settings for each workspace (derby). -Matej On Thu, Jul 17, 2008 at 12:46 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > I think we do need a pooling for all the jdbc connections in > Jackrabbit. But that should be possible without managing DataSources > within Jackrabbit. DataSource management itself is clearly a task of > the container or servlet engine and would create too much additional > code that needs to be maintained - and ensured to be standards > compliant. > > Regards, > Alex > > On Wed, Jul 16, 2008 at 7:30 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: >> Hi, >> >> the thing is, not everyone is running jackrabbit in a servlet >> container and not every servlet container uses JNDI. Also I think >> creating DataSource that acts as a proxy for another JNDI obtained >> DataSource should be fairly trivial. >> >> -Matej >> >> On Wed, Jul 16, 2008 at 2:06 PM, Marcel Reutegger >> <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> I think jackrabbit should not manage data sources but rather obtain them >>> through JNDI. there are lots of existing JNDI implementations and containers >>> that allow you to configure data sources and make them available through >>> JNDI. >>> >>> regards >>> marcel >>> >>> Matej Knopp wrote: Hi, we've encountered a serious problem with jackrabbit - keeping a database connection for each active workspace. A jira entry already exists [1] and it's targetted for 1.5, but so far there hasn't seem to be much activity. I'm willing to provide a patch that might be of some help to you, but first I'd like to have some things clarified of how the thing should work (from user perspective). My idea so far is to have new config section (toplevel, inside ) that would allow to register data sources Something like Multiple data sources could be defined per repository. Jackrabbit would create and manage data source instances (each class is required to implement DataSource interface). All components that require a SQL connection would have dataSource attribute that would specify the data source instance. i.e. >>> class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager"> Alternatively there might be also a way to register data source per workspace, so the instance would be workspace specific. Though I personally don't see much value in this. It would be great to get any feedback on this. Kind regards, -Matej Knopp [1] https://issues.apache.org/jira/browse/JCR-1456 >>> >>> >> > > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
Re: Connection pooling
I think we do need a pooling for all the jdbc connections in Jackrabbit. But that should be possible without managing DataSources within Jackrabbit. DataSource management itself is clearly a task of the container or servlet engine and would create too much additional code that needs to be maintained - and ensured to be standards compliant. Regards, Alex On Wed, Jul 16, 2008 at 7:30 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Hi, > > the thing is, not everyone is running jackrabbit in a servlet > container and not every servlet container uses JNDI. Also I think > creating DataSource that acts as a proxy for another JNDI obtained > DataSource should be fairly trivial. > > -Matej > > On Wed, Jul 16, 2008 at 2:06 PM, Marcel Reutegger > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I think jackrabbit should not manage data sources but rather obtain them >> through JNDI. there are lots of existing JNDI implementations and containers >> that allow you to configure data sources and make them available through >> JNDI. >> >> regards >> marcel >> >> Matej Knopp wrote: >>> >>> Hi, >>> >>> we've encountered a serious problem with jackrabbit - keeping a >>> database connection for each active workspace. >>> A jira entry already exists [1] and it's targetted for 1.5, but so far >>> there hasn't seem to be much activity. >>> >>> I'm willing to provide a patch that might be of some help to you, but >>> first I'd like to have some things clarified of how the thing should >>> work (from user perspective). >>> >>> My idea so far is to have new config section (toplevel, inside >>> ) that would allow to register data sources >>> >>> Something like >>> >>> >>> >>> >>> >>> >>> >>> Multiple data sources could be defined per repository. >>> >>> Jackrabbit would create and manage data source instances (each class >>> is required to implement DataSource interface). >>> >>> All components that require a SQL connection would have dataSource >>> attribute that would specify the data source instance. >>> >>> i.e. >>> >>>>> >>> class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager"> >>> >>> >>> >>> >>> >>> Alternatively there might be also a way to register data source per >>> workspace, so the instance would be workspace specific. Though I >>> personally don't see much value in this. >>> >>> It would be great to get any feedback on this. >>> >>> Kind regards, >>> -Matej Knopp >>> >>> [1] https://issues.apache.org/jira/browse/JCR-1456 >>> >> >> > -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Connection pooling
Hi, the thing is, not everyone is running jackrabbit in a servlet container and not every servlet container uses JNDI. Also I think creating DataSource that acts as a proxy for another JNDI obtained DataSource should be fairly trivial. -Matej On Wed, Jul 16, 2008 at 2:06 PM, Marcel Reutegger <[EMAIL PROTECTED]> wrote: > Hi, > > I think jackrabbit should not manage data sources but rather obtain them > through JNDI. there are lots of existing JNDI implementations and containers > that allow you to configure data sources and make them available through > JNDI. > > regards > marcel > > Matej Knopp wrote: >> >> Hi, >> >> we've encountered a serious problem with jackrabbit - keeping a >> database connection for each active workspace. >> A jira entry already exists [1] and it's targetted for 1.5, but so far >> there hasn't seem to be much activity. >> >> I'm willing to provide a patch that might be of some help to you, but >> first I'd like to have some things clarified of how the thing should >> work (from user perspective). >> >> My idea so far is to have new config section (toplevel, inside >> ) that would allow to register data sources >> >> Something like >> >> >> >> >> >> >> >> Multiple data sources could be defined per repository. >> >> Jackrabbit would create and manage data source instances (each class >> is required to implement DataSource interface). >> >> All components that require a SQL connection would have dataSource >> attribute that would specify the data source instance. >> >> i.e. >> >>> >> class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager"> >> >> >> >> >> >> Alternatively there might be also a way to register data source per >> workspace, so the instance would be workspace specific. Though I >> personally don't see much value in this. >> >> It would be great to get any feedback on this. >> >> Kind regards, >> -Matej Knopp >> >> [1] https://issues.apache.org/jira/browse/JCR-1456 >> > >
Re: Connection pooling
Hi, I think jackrabbit should not manage data sources but rather obtain them through JNDI. there are lots of existing JNDI implementations and containers that allow you to configure data sources and make them available through JNDI. regards marcel Matej Knopp wrote: Hi, we've encountered a serious problem with jackrabbit - keeping a database connection for each active workspace. A jira entry already exists [1] and it's targetted for 1.5, but so far there hasn't seem to be much activity. I'm willing to provide a patch that might be of some help to you, but first I'd like to have some things clarified of how the thing should work (from user perspective). My idea so far is to have new config section (toplevel, inside ) that would allow to register data sources Something like Multiple data sources could be defined per repository. Jackrabbit would create and manage data source instances (each class is required to implement DataSource interface). All components that require a SQL connection would have dataSource attribute that would specify the data source instance. i.e. Alternatively there might be also a way to register data source per workspace, so the instance would be workspace specific. Though I personally don't see much value in this. It would be great to get any feedback on this. Kind regards, -Matej Knopp [1] https://issues.apache.org/jira/browse/JCR-1456
Re: Connection pooling
I think it is a good idea, Jukka has also already given some ideas on how to implement it in JCR-1456. A patch is always welcome, especially now, since most core developers are focused on other things and 1.5 is not so clearly on the horizon ;-) Regards, Alex On Wed, Jul 16, 2008 at 2:33 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Hi, > > we've encountered a serious problem with jackrabbit - keeping a > database connection for each active workspace. > A jira entry already exists [1] and it's targetted for 1.5, but so far > there hasn't seem to be much activity. > > I'm willing to provide a patch that might be of some help to you, but > first I'd like to have some things clarified of how the thing should > work (from user perspective). > > My idea so far is to have new config section (toplevel, inside > ) that would allow to register data sources > > Something like > > > > > > > > Multiple data sources could be defined per repository. > > Jackrabbit would create and manage data source instances (each class > is required to implement DataSource interface). > > All components that require a SQL connection would have dataSource > attribute that would specify the data source instance. > > i.e. > > class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager"> > > > > > > Alternatively there might be also a way to register data source per > workspace, so the instance would be workspace specific. Though I > personally don't see much value in this. > > It would be great to get any feedback on this. > > Kind regards, > -Matej Knopp > > [1] https://issues.apache.org/jira/browse/JCR-1456 > -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Connection pooling
> Alternatively there might be also a way to register data source per > workspace, so the instance would be workspace specific. Though I > personally don't see much value in this. Actually, this might be required for Derby and possibly other managers that require different connection URL per workspace. -Matej
