There still is some odd behavior when closing resources in finally blocks in Ashok's code. Only the final statement will throw a ServiceAccessException on error while closing. I'd say either throw always or never...

So, always or never?

Oliver

Oliver Zeigermann wrote:

OK. I think we waited long enough...

So, we decided to use the adapter thing!

My proposal is to take over Ashoks DB design completely and make the SQL stuff an adapter. I have seen some weired non-transactional caching of ids in the old StandardRDBMSAdapter that should better be handled by index (what is the plural of index?). That's what is done in Ashoks design :) So, I will only add ordering to ACE's in this first shot.

Comments? Is this ok for everyone?

I will start working anyhow and will tell you as soon as I have something.

Oliver

Oliver Zeigermann wrote:

[EMAIL PROTECTED] wrote:

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?



Well with the adaptor then different DB optimizations maybe more easily accommodated. Also I prefer more structure that one big store class. What we have today grew out of something smaller.



Well, the adapter really is big as well...


But, I do not mind too much, as in my opinion it is simply a matter of taste. As I said, I want to have something everyone can live with. So, let's have a vote upon this. Whatever you people decide, I will do...

So, everyone, votes please!

Oliver



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


.






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


.






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to