[ http://issues.apache.org/jira/browse/JCR-313?page=comments#action_12365003 ]
Martin Perez commented on JCR-313: ---------------------------------- [OT]: Well, first of all, sorry if I offended someon putting the issue, because it seems that I got hard responses. Take in mind that I only wanted to help when one person of your team asked to someone to put the issue. I do not have special interest on this topic, even taking in mind that I think that it would be a good improvement. > Why do you think that using a DataSource instead of a plain SQL Connection > has any impact on concurrency, performance or transactions? Well, with all the respects, one simple reason to boost concurrency, performance and transactions is that is the application server who manages the resources, and not you manually. This is enough to justify, nor only because modern application servers can perform extra optimizations on db connections and by consequence impacting on the three items above, but the extra system security layer that you get. Accessing in a non-managed way to managed resources from managed environments is always, at least, not-the-better option, but this is only my opinion. And after that reason, that I think is the most important, we could start to talk about connection pooling, transactions or synchronization. Anyways, I'm not going into that as it was being discussed on the list. I endorse most of the comments given there. Yes, I know, like you said (and you did a great and very instructive response), that many of the items exposed do not always happen, or that they are not quite true. But they can happen, and in that case jackrabbit won't scale, and that is the really important thing, and by consequence all the three items exposed above will be decreased. >i wouldn't be against a more elaborate JDBC based PM implementation that makes >use of J2EE infrastructure features such as JNDI lookup of the DataSource, etc. Sure! If you want to add more things than JNDI support, maybe it could be worthwile. You can know that better than I , as you know better the code. But ( and please, forgive me because I'm talking without deeply SDPM knowledge) it seems to me that adding a DataSource lookup method should not be very difficult. My only doubt if it will be enough with a simple InitialContext instantiation or you will need to start thinking about passing special parameters to the JNDI environment. And well, if you have the lookup, then all the code is done; you only have to add the necessary close() methods. Also, think that you have to evaluate if it has sense to have two different generic database persistence manager. For me, I think that is better and also less confusing for the final users to have a single good database persistence manager. But again, this is only my opinion. > Allow to configure DB persistence managers through JDNI > ------------------------------------------------------- > > Key: JCR-313 > URL: http://issues.apache.org/jira/browse/JCR-313 > Project: Jackrabbit > Type: Improvement > Versions: 0.9 > Reporter: Martin Perez > > Currently, DB persistence managers have hardcoded urls. Even more, they will > use a single connection with the drawbacks that this have regarding > concurrency, performance and transactionality. > It would be fairly better to allow to configure DB persistence managers > through JDNI references to DataSource. So giving responsability to > application server. Concurrency, performance and transactionability will be > highly boosted with this approach. > This could be a sample configuration : > <PersistenceManager > class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager"> > <param name="dataSource" value="jdbc/JackrabbitDS"/> > > .... think also about a way to pass params to data source, it should > be simple .... > <param name="schema" value="mysql"/> > <param name="schemaObjectPrefix" value="${ > wsp.name}_"/> > <param name="externalBLOBs" value="false"/> > </PersistenceManager> -- 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
