topic Re: Activiti 6 pluggable persistence feedback in Alfresco Archive

Activiti 6 pluggable persistence feedback

bjoern_s — Fri, 20 Nov 2015 14:10:11 GMT

Hello,I do not need any help here, this is just a feedback I like to share my first experience using the new pluggable persistence facility. My current use case is to completely replacing the "core" persistence implementation by a Hibernate JPA based implementation. This works well so far, but I

Re: Activiti 6 pluggable persistence feedback

jbarrez — Thu, 11 Feb 2016 11:25:02 GMT

Hi Björn, finally got time to review this:

1. True. The workaround would be to have a custom BPMNDeployer I would guess. The special way of handling that id is because of the process definition being cached.

2. Not sure if I see the problem here. Wouldn't you simply be able to extend those classes in your own implementation? I'm not sure this would be an easy change.

3. Correct. This has been fixed on the activiti6 branch last week.

4. I can see your point. But it's probably hard to refactor that without breaking a lot of people's code … With JPA lazy loading/etc it still could work, right, you would have to check if some property is already loaded.

5. Correct. Has been fixed on the activiti6 branch.

Re: Activiti 6 pluggable persistence feedback

bjoern_s — Fri, 12 Feb 2016 09:22:04 GMT

Thank for your reply!

->2. Right, so did I. This was not a real issue, just an inconvenience.
->4. Found a way to handle this, most of the "*DataManager*" now fetch the owning JPA Entity and iterate the collections instead of performing a DB query. I re-implemented all relations as JPA collections with ManyToOne and OneToMany. This of course requires all "back link collections" to be filled (5.) to be useable within the same transaction. This is works really fast - most of the JPA first and second level caching mechanism can be used. Indeed we can only support the required minimum for the query operations, but this is ok.

I continued my JPA+Activiti jurney and I it worked quiet well so far. You did an amazing job with the activiti project. If it helps, I continue to give some feedback. I have found some minor points (which I was able to work around using your powerful interfaces). I needed to:

6. subclass org.activiti.engine.impl.variable.SerializableType to remove two calls to Context.getCommandContext().getDbSqlSession() (this does not exist in JPA)
7. subclass org.activiti.engine.impl.persistence.entity.HistoricDetailEntityManagerImpl to remove/replace the setting of the ByteArray handling (maybe already fixed)
8. subclass org.activiti.engine.impl.el.VariableScopeElResolver setValue to set context.setPropertyResolved(true) to prevent resolving the property while in the same transaction (where the property may not be flushed to the JPA db yet)

Re: Activiti 6 pluggable persistence feedback

jbarrez — Tue, 16 Feb 2016 12:36:14 GMT

Thanks for the kinds words. Much appreciated!

4. Great to hear. That's indeed the way I would have done it too.

6. This has been removed on master 🙂

7. Yup, should be fixed.

8. hmmm that sounds interesting. Can you explain with an example … i don't think I'm fully grasping what you're trying to say here.