If you reposted and donated the latest version of your code I will promise to do my best to merge it with the other versions / branches. This could be good for us all, as our efforts can be combined!
Anyway (just observations / questions, no exposing or anything like this):
1.) There is this closing of resources issue:
- In the CVS version of org.apache.slide.store.impl.rdbms.J2EEStore result sets never get closed.
- In the CVS version of slidestore.j2ee - additional to not closing the result sets - statements get closed at least twice.
- Willy Wu fixed this in his version by nulling the statement, but also forgets about result sets. Instead, he closes the connection in final blocks. This of courses closes all enclosed resources, but the price is he has to get a new connection for every statement (a high price measured in performance penalty). I wonder how this can possibly work with pooled connections anyhow, but I am no expert.
- In Ashok's posted store from January you see this kind of thing very often
finally
{
try
{
if ( res != null) {
res.close();
}
if ( statement != null) {
statement.close();
}
}
catch(SQLException e)
{
getLogger().log(e, super.LOG_CHANNEL, Logger.ERROR);
throw new ServiceAccessException(this, e);
}
}If you take a closes look you will see statement will not be closed when res.close() rises an exception. Admittedly, this is unlikely, but why risking this? Maybe it is fixed in your code, already? I know it is ugly, but maybe like this:
try { if ( res != null) res.close(); } catch(SQLException e) { }
try { if ( statement != null) statement.close(); } catch(SQLException e) { }or even more robust than robust ;)
try { if ( res != null) res.close(); } catch(SQLException e) { } finally {
try { if ( statement != null) statement.close(); } catch(SQLException e) { }
}
2.) Why do you think the approach in org.apache.slide.store.impl.rdbms is better than yours? Why is there an adapter? Also, where do you see a nicer Java approach?
3.) I do not think org.apache.slide.store.impl.rdbms.J2EEStore does an auto-commit, but the other way round. It sets auto-commit to false. Although, it seems doing this causes trouble as indicated in
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03381.html
4.) I agree merging both stores is more robust as otherwise you would need a real two-phase-commit database implementation. Most databases in use do not provide this...
5.) Compressing blobs sounds interesting...
Given the obervations above and my *personal* impression your store seems to be the most mature, so it would be of great help if you donated the latest version of your code!
Thanks so far Colin! Thanks to Ashok as well!
Oliver
[EMAIL PROTECTED] wrote:
The slidestore.j2ee.J2EEStore work was done by Ashok to provide a merged store, which is transactionally correct. We use a version of it in our product.
We discovered in the original J2EEStore model, where the stores were
separate classes that the transactions were not clean and database
deadlocks could occour. The issue was locking of tables could occour
when multiple transactions worked at the same time or when large files
were added, in addition when transmission problems occurred rollbacks
did not complete cleanly. The DB pooling (we use Jakarta DBCP in Tomcat)
would end up using two separate transactions for the two stores and this
clearly created those issues.
The merged stores use a common connection for both content and descriptors which is tied to a slide transaction, this stops the deadlocks and ensures accurate rollback. In addition we added the ability to compress the content going into the blob of the DB using zip compression. We found when using large XML files this improved overall performance.
I believe that org.apache.slide.store.impl.rdbms.J2EEStore is a refactor of the slidestore.j2ee.J2EEStore , this uses an adaptor and generally a nicer Java approach, but I believe was not finished. I am not sure if it corrected/dealt with the transactional issues, but from a brief look it auto-committed the connection so I am not sure it does transactions cleanly.
Hopefully that helps some. We can re-post the latest version of the
store we use. It has been tested with the latest from CVS, but really it
needs refactoring into the same style as
org.apache.slide.store.impl.rdbms.J2EEStore .
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
