Using Transactional (No Autocommit)

[Ali]

I was wondering if there is a way to use nflow with transaction support. When I disable auto commit I get an exception:

DataSource must have auto commit enabled

How can I get Nflow engine working without auto commit? (I use mysql)

[Mikko Tiihonen]

It is generally a good idea to run with auto commit enabled. Using any transaction framework will always automatically disable auto commit for the duration of the transactions.

When running simple SQL statements relying on auto commit requires less round-trips to the database and thus shortens also the time locks are held in database improving scalability.

Of course not every database operation can be written in single statement and then transactions need to be used. nFlow uses them only when needed to for correct functionality.

There are lots of risks if auto commit is disabled and the application runs statements that modify the database outside a transaction framework. I've seen a large project where there were occasional updates and lots of reads. It took a long time to debug a case why the db reported a deadlock for two items that were touched many minutes apart. Root cause was that @Transctional annotation was missing from one place.

If you have a use case for running with auto commit disabled I would be very interested to hear. If there is a valid need, it will be of course possible to make nFlow allow disabling auto commit outside of transactions too.

[Ali Wisterr]

I was trying to embed it within my spring boot application for which I couldn't support autocommit. Anyways, there is no other valid need related directly to nflow.

Overall, I think the product is solid and works well for what it was designed to do. Hats off.

The only gap I see is user assignment. The user should be a first class citizen, and should be able to query instances by user id, and/or assign them to user ids. Is that something being considered for nflow?

[Mikko Tiihonen]

Overall, I think the product is solid and works well for what it was designed to do. Hats off.

The only gap I see is user assignment. The user should be a first class citizen, and should be able to query instances by user id, and/or assign them to user ids. Is that something being considered for nflow?

User is a quite specific concept for lower level utility like nFlow to have. But there are few ways to associate more data with workflows.
 
1) The simplest is to use the businessKey field of the workflow instance. You can set it on creation to your user identifier and use it to search for workflows for specific user later. Caveat: we do not currently support updating that field.
 
2) An alternative is to just add more metadata as state variables to the workflow. And they can of course be updated. Caveat: there is no easy way to search for with state variables. But the information will be readily available for the workflow during execution.
 
3) The complex scenario is to create a separate table where you store your user and other metadata and link to it using the businessKey field.

[Ali Wisterr]

Thanks for the update.

I actually tried the first approach, and learnt the hard way that businessKey can't be modified. However, adding an extra field such as businesskey that's updatable should do the trick and would be valuable for the use case nflow serves.

The other 2 approaches limit the power of using the rest api directly which makes nflow really appealing. I did end up going with (2) though with front-end filtering.

[nflow-users]

FYI: Caveats of 1) and 2) will be fixed in 7.2.3, which will include support for updating business key and searching by state variable key+value.

7.2.3-SNAPSHOT is already available in https://oss.sonatype.org/content/repositories/snapshots/io/nflow/

br, Edvard