I discussed that issue with Tom via email already as well. So I will provide the stuff from there here as well:
– BERND
Hi Tom.
You wrote in your blog:
But I would be really interested to find out why you want to plug your own persistence provider. If it is for another storage then JDBC, then I can understand. But if we work with your JDBC connection and your persistence framework also translates to JDBC, does it matter what persistence framework we use internally?
Let me give a quick answer from my side, I see three reasons for JPA against iBatis:
1.) As we promote tu use standards (BPMN) it would be cool to do that where possible
2.) I saw a lot of companies / projects having clear rules which persistence frameworks are allowed. Not sure if that was only a problem with Hibernate, but with jBPM Hibernate was a showstopper for some projects
3.) And this is the most important: If you build big applications you have to know the nuts and bolts of the persistence framework, e.g. for caching, clustering, and so on. This is normally true for Hibernate, but I don’t know many projects or companies using iBatis. But for Hibernate I know excellent experts (and you need them sometimes ;-)).
On the pro side for sure the license is an argument. And it is already too late to change it I guess, so anyway. But just to have said I am not that happy with it as well…
– Tom's answer:
we first tried open jpa but it was too clumsy in development. hibernate is good to work with but its LGPL so no go
switching to ibatis put a bit more burden on us, but it also has a benefit of more control. hibernate is most of the times really good, but still it has these magical flushes. fixing problems related to flushes can be very challenging with hibernate. with ibatis you know what happens, when and how and you're in full control.
but is's not religious for us. but we have to have good arguments. currently i'm quite happy with ibatis.
> 1.) As we promote tu use standards (BPMN) it would be cool to do that where possible
(i agree with some of your argumentation, but it's just quicker if i play devil's advocate here)
JDBC is standard too. using as much standards as possible in your persistence layering shouldn't be a goal 😉
> 2.) I saw a lot of companies / projects having clear rules which persistence frameworks are allowed. Not sure if that was only a problem with Hibernate, but with jBPM Hibernate was a showstopper for some projects
i don't see ibatis being a problem. it's only JDBC that comes out.
> 3.) And this is the most important: If you build big applications you have to know the nuts and bolts of the persistence framework, e.g. for caching, clustering, and so on. This is normally true for Hibernate, but I don’t know many projects or companies using iBatis. But for Hibernate I know excellent experts (and you need them sometimes ;-)).
with ibatis you don't need those experts. it's us in full control and the code is readable and predictable.
– BERND
Another argument, especially for an open source project: A lot of people are not familiar with ibatis.
– BERND
Today I had a discussion with an architect at a big company. He told me that currently no other persistence mechanism as Hibernate is deployed on the machines here, since they invested a lot of money to get that running correctly in a clustered environment, together with JMS, JTA etc…
Normally people ask for JPA, here Hibernate is fixed. So this could be a show stopper to run Activiti 😕
I will have a look into the code base to see how the persistence is pluggable (which I am sure it has to be for being Cloud deployable). It would be really good to have JPA ready in my opinion. Nobody really knows ibatis 😕
– TOM
i think we have to protect those type of architects against themselves 😉
in my jbpm 1 days, i'ld say of course it's pluggable already with the persistence session.
but the argument of their expertise in hibernate does not hold. i can guarantee that they will be working with a debugger and asking for our help which we can't give them. if they follow whatever persistence framework that we use, we will have done our clustering QA and they should not have to use a debugger.
why do they want to organize their architecture on the persistence framework, rather then JDBC. that looks like a broken strategy to me.
when we switched from hibernate over OpenJPA to EclipseLink we had very different errors. and that is switching between *JPA* providers. i don't see the point in spending our time on that. and I think most people will underestimate the work.
although i'm very convinced that there is no valid argumentation for us to support multiple persistence providers, i think might still can consider it because embeddablility is in our core values. and if 80% of developers consider persistence framework as part of the app environment that we have to embed into, then at least we should consider it.
but my current belief is that supporting multiple persistence implementations is 1) it's a waste of our time and 2) not feasible with the resources we have.
