Business Transaction Best Practice

[Bon Bon]

I really love Vert.x for its own non-blocking architecture.
Just one thing I do not understand is, there is no built-in support for transaction management.
As my experience, every application needs to manage business transaction even it is small or big unit of work.
So, could anyone share experience in working with transaction in Vert.x?
(1) We should manage transaction manually? How?
(2) We should delegate business process to enterprise message bus like RabbitMQ, ActiveMQ to manage transaction? How?
(3) We should let it crash? How business design will become?
(4) Vert.x should not be used for enterprise application?

Again, I really love Vert.x, but I can not go futher without transaction management.
Thanks!

[Tim Fox]

Vert.x *itself* doesn't need to support transactions any more than, say, Tomcat needs to support transactions (or Node.js, or....)

That doesn't mean you can't use Vert.x with some other transactional resource (e.g. a database)..

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bon Bon]

Sorry for my bad English, I did not mean Vert.x needs to support transactions.
What I mean is an official module comes together with Vert.x can support (configure?) transaction easily like

(1) Unit of work
// begin transaction
// do your own business
// commit/rollback transaction

(2) AOP + Provider
@Transactional + DB Transaction Provider, and everything just work like charm.

Or if I have to manage transaction manually, how is the best practice to archive the context above?

Thanks!

[Tim Yates]

You have to roll your own transaction handling

The JDBC persistor I wrote has an example

https://github.com/timyates/mod-jdbc-persistor/blob/master/README.md#transaction
https://github.com/timyates/mod-jdbc-persistor/blob/master/src/main/java/com/bloidonia/vertx/mods/JdbcProcessor.java#L411

[Bon Bon]

This is amazing, I will give it a try!
But one thing I'm confused is:
How the transaction and connection working together in the context of multiple processing:

// get DB connection

// UNIT OF WORK 1
// task1: start TRANSACTION1 (async)
// task1: do business like EXECUTE UPDATE in TRANSACTION1 (in Connection ??, async)
// task1: end TRANSACTION1 <~ ROLLBACK/COMMIT (async)

// UNIT OF WORK 2
// task2: start TRANSACTION2 (async)
// task2: do business like EXECUTE UPDATE in TRANSACTION 2 (in Connection ??, async)
// task2: end TRANSACTION2 <~ ROLLBACK/COMMIT (async)

The tasks above can be come from multiple users or mods, asynchronously.
How can I (or mod-jdbc-persistor) guarantee UNIT OF WORK2 will not COMMIT/ROLLBACK business of UNIT OF WORK1?

Thank you for saving my life!!!

[Mark Little]

I can't stress enough how rolling your own transaction management is a really bad thing :-)

If you need to do something like this then why not look at integrating a transaction manager, such as Narayana (part of the JBoss project suite)? At leas then it'll take care of the enrolment of resource managers and auto-recovery in the event of a failure. Plus the Narayana team have been working on allowing non-XA resources, such as MongoDB, to be added to the scope of a global transaction, which may be useful to some on this list.

Mark.

[Bon Bon]

Actually I have read Narayana during the time looking for transaction solution through:
http://jbossts.blogspot.com/2013/03/stm-vertx-and-pi-part-1.html

* Maybe my mistakes (because of my litte knowledge that I'm trying to improve):
(1) Thought that Narayana was tested and run only on the "Pi"
(2) Whether Narayana STM was blocking or non-blocking thread.
If there is an example like use-case, I'd love to try!!!

* IMO, JDBC Persistor is awesome.
Just one thing I'm confusing is how to use JDBC Persistor for my use-case above.

Thanks for being kind to me!!!

[Mark Little]

On 20 Jun 2014, at 16:40, Bon Bon <bon...@gmail.com> wrote:

Actually I have read Narayana during the time looking for transaction solution through:
http://jbossts.blogspot.com/2013/03/stm-vertx-and-pi-part-1.html

* Maybe my mistakes (because of my litte knowledge that I'm trying to improve):
(1) Thought that Narayana was tested and run only on the "Pi"

Oh no. It's been around since 1996 (was called Arjuna back then). Actually goes back to 1986 in C++.

You probably saw my porting of it to the Pi a couple of years ago. I tend to use Narayana as the project to learn new environments, languages etc :-)

(2) Whether Narayana STM was blocking or non-blocking thread.
If there is an example like use-case, I'd love to try!!!

Well the STM component of Narayana is separate from the traditional database aspects, such as JTA, JCA-plugin.

The STM component is under review at the moment (well, Tim is looking at it). But it's a self-contained beast that doesn't require a datastore, since most STM implementations are for volatile (non-durable) memory interactions.

* IMO, JDBC Persistor is awesome.
Just one thing I'm confusing is how to use JDBC Persistor for my use-case above.

Thanks for being kind to me!!!

Glad to help. Just seen so many people try to roll their own transactions over the last 30 years and it really isn't worth it.