topic Re: Implementation of Persistence in Alfresco Archive

Implementation of Persistence

chrisc — Fri, 15 Jul 2011 11:12:18 GMT

Congratulations on your work with Activiti. I was looking at jBPM 4 but realized that jBoss' support for it seems to be waning.It appears as though jBoss used Hibernate for its persistencet. Does Activiti use an ORM for it's persistence?I was hoping to find a BPM engine that persists it's objects us

Re: Implementation of Persistence

ronald_van_kuij — Sat, 16 Jul 2011 15:22:47 GMT

Activiti uses iBatis. There is a topic which describes the 'why'.

JDO is old, so using yet another abstraction layer to have either JDO, JPA or Hibernate is imo a solution that is even more wrong. But if you decide you want a JPA(2?) based persistence layer, I'm willing to help out as wel. But…

The persistence of Activiti is completely hidden. You can share transactions if you use JTA, you can even inject your own datasource, you can persist JPA entities from their own entitimanager as process variables etc… So there is no real problem here, at least I've not seen/encountered any. Yes, there are maybe certain CTO's or 'architects' requirering an uniform persistence layer in 'their applications', but these people should be fired for their incompetence. 🙂

And where did you read that only H2 is supported? Just read the docs. It is true that the demo setup is reduced to only supporting H2 easily out of the box, but that is imo a good choice. So many people that were not competent enough, were doing wrong things that the number of posts about this in the forum caused to much work (these people often did not search the forum etc). In addition the time to make it even simpler is simply not there. People that realy want to use a different db and are capable, will achieve this easily.

Re: Implementation of Persistence

gregory1 — Mon, 28 Nov 2011 09:09:44 GMT

The persistence of Activiti is completely hidden, but it is not the best solution in every case.
Let's talk about the situation when there is a requirement to display data joined from two different subsystems (one of them is bpm).
It's much easier to make such join on lower level (like db or jpa) then querying and joining results in format determined by Activiti API with something else (e.g. JPA entities), and applying any additional elements like filtering, sorting, etc.

So, maybe there are certain CTO's or 'architects' requirering an uniform persistence layer in 'their applications', but it doesn't make them incompetent.

Re: Implementation of Persistence

ronald_van_kuij — Mon, 28 Nov 2011 18:38:44 GMT

What data would you like to join?

Re: Implementation of Persistence

heymjo — Wed, 30 Nov 2011 07:29:11 GMT

a simple example of joining data: when a task is assigned we store the user id in the assignee field. When the list of assigned tasks is displayed in an application we need to show the assignee full name.

our options:

1) store the full name as a process variable upon assignment
2) upon retrieval of the tasks join against a user table that has the complete info
3) after the tasks are retrieved from activitiy, wrap the taskentities and add getFullName where we do a lookup in the user table.

We went for 3) but 2) would have been nicer. 1) seemed ugly.

Re: Implementation of Persistence

ronald_van_kuij — Fri, 02 Dec 2011 14:51:38 GMT

Since user data is used and retrieved very often, we kind of 'cache' that (memory is cheap) The 'joining' takes place in the ui layer (jsf). Works great and performs great as well.

Other usecases?

Re: Implementation of Persistence

heymjo — Tue, 06 Dec 2011 08:47:38 GMT

yes we cache the user info in a map as well now, works fine. So if you want other cases then use your imagination 🙂

Re: Implementation of Persistence

oleksandr — Thu, 17 Sep 2015 15:46:53 GMT

In light of Activiti 6, what do I need to do to use for example Hazelcast instead of RDBMS as storage for my processes?