Refactoring access to JBPM database

[rjoachim]

Reviewing current JBPM codebase, it seams to me that you intend to move all database specific code of JPDL into the different Session classes in org.jbpm.db package to make persistence provider plugable.

If that is your intention I am willing to contribute in that area as I like to use a different persistence provider together with JBPM.

Are there already some open issues? If there are no open issues I would create one head task with a bunch of small subtasks. According to my experience the small subtasks will make review much easier for the committer.

Is anyone of the committeres willing to assist me with this?

[tom.baeyens]

The sessions don't really intent to provide an pluggable persistence.

What technology do you have in mind ?

IMO, only JPA could be considered. But we are only researching if that kind of pluggability is feasible for jbpm 4.

[rjoachim]

I agrre with you that only JPA is a considerable target for another persistence provider integrated with JBPM. But even if I agree with you on that I need to implement support for another provider. What I intend to contribut is only the refactoring of JBPM to allow implementation of adaption layers to different persistence providers.

What I have in mind is to move all code that interacts with a persistence provider into the Session classes (e.g. GraphSession) in org.jbpm.db package. Having said that there are still some references to Hybernate classes that i do not have an idea yet how this could be achived (e.g. org.jbpm.persistence).

As a second step the Session classes could be converted to interfaces with Hybernate specific implementations. It still need to be discussed how that implementations are instantiated but propably a factory would be a good idea.

[tom.baeyens]

i'm curious to know which other persistence technology you plan to support and how you plan to handle things as lazy loading during object navigation ?

[rjoachim]

I need to integrate JBPM with an already existing application that uses Castor as persistence layer.

Castor already supports lazy loading even if it is a bit buggy. Having said that I intend to fix such stuff in the adapter layer or in Castor where I'm a commiter at for quite some time.

[tom.baeyens]

castor uses a jdbc connection, right ? then why don't you just leverage a single JDBC connection and give that to jbpm and castor.

i can't see why would would like to go through all the trouble of trying to implement a new persistence layer on jbpm.

i think such tasks are very easy to underestimate and they don't bring value.

don't focus too much on simplifying your application architecture. focus on what gives you robust and proven software solutions. your overview schema might become a bit more scattered, but you'll save a heck of a lot of time to go to the beach and the result will be a lot less buggy.

that's just my free advice.

[rjoachim]

Well, that's how things work for about a year now and as it seams you don't like a plugable persistence architectur for JBPM, we'll continue with that workaround.

Having said that I personally do not like it with regard to project dependencies.

[kukeltje]

Tom said nothing about not wanting a plugable architecture... What he said was the making jBPM use JPA would make it pluggable with regard to the JPA implementation (hibernate or whatever)

Correct me if I'm wrong

[rjoachim]

You are right, but that target does not fit to my requirements and I therefore will not spend time to work on it. On the other hand would my target have made it much easier for someone else to add support for a JPA persistence layer.

As it seamed to me that I wouldn't get the required support from the JBPM team to succeed with my task I changed my mind and moved on to other targets. What I can offer is to share 2 small patches of the refactoring that I have finished until now. Having said that still all tests execute without failures that have not been broken by other commits from end of last week.