asyncTransactionChain right way to create a new Entity

38 views
Skip to first unread message

lbedu...@gmail.com

unread,
Dec 12, 2014, 6:41:09 AM12/12/14
to activate-p...@googlegroups.com
Hello, 

I am new to Activate framework and I am testing Activate async support.

It seems to work great except that I had a hard time making an async transaction

I lost 1 hour fighting with a net.fwbrasil.radon.RequiredTransactionException

  asyncTransactionalChain { implicit context =>
    .... more work inside the transaction ...
    new MyEntity("Pierre")
    .... more work inside the transaction ...
  }

Turned out I had to delimit the Entity creation with a future :

import scala.concurrent._

  asyncTransactionalChain { implicit context =>
    .... more work inside the transaction ...
    future { new MyEntity("Pierre") }
    .... more work inside the transaction ...
  } 

I don't know if it's really that OK nor if a rollback would work (have to test it) but it's the only solution I found to create a new Entity inside the asyncTransaction.

Maybe the doc should explain this (maybe I am tired and missed the example too:)

Regards
Laurent

Flavio W. Brasil

unread,
Dec 12, 2014, 6:45:48 AM12/12/14
to lbedu...@gmail.com, activate-p...@googlegroups.com
Hi Laurent,

The asyncTransactionalChain is designed to be used when using queries that produce other futures.
If the transaction doesn’t have a query the method to be used is asyncTransactional, so your code would be:

  asyncTransactional {
new MyEntity("Pierre")
  } 

Let me know if the explanation clarifies. :)

Cheers,

-- 
Flavio W. Brasil

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

Laurent Bedubourg

unread,
Dec 12, 2014, 7:43:27 AM12/12/14
to Flavio W. Brasil, activate-p...@googlegroups.com
The asyncTransactionalChain is designed to be used when using queries that produce other futures.
If the transaction doesn’t have a query the method to be used is asyncTransactional, so your code would be:

  asyncTransactional {
new MyEntity("Pierre")
  } 

Let me know if the explanation clarifies. :)

Hi Flavio,

I just tested Entity creation inside asyncTransactionalChain and the rollback works perfectly with future.

asyncTransactionalChain { implicit context => 
   ... some queries necessary to create my Entity here ...
   future { new MyEntity("aaa") }
   ... more queries ...
   throw new Exception("Rollback please")
   ... dummy ...
}

Because I am curious I tried to replace, in the above code,

future { new MyEntity("aaa') }

with

asyncTransactional { new MyEntity("aaa") }

The MyEntity aaa appeared in mongo, I don't know if it's the same for the regular transactional feature but is it possible to reuse the current transaction or at least to throw some error when a sub transaction is started ?  (I am using activate v 1.7)

Best regards and thank you Flavio

Laurent


Cheers,

-- 
Flavio W. Brasil

On Friday, December 12, 2014 at 12:41 PM, lbedu...@gmail.com wrote:

Hello, 

I am new to Activate framework and I am testing Activate async support.

It seems to work great except that I had a hard time making an async transaction

I lost 1 hour fighting with a net.fwbrasil.radon.RequiredTransactionException

  asyncTransactionalChain { implicit context =>
    .... more work inside the transaction ...
    new MyEntity("Pierre")
    .... more work inside the transaction ...
  }

Turned out I had to delimit the Entity creation with a future :

import scala.concurrent._

  asyncTransactionalChain { implicit context =>
    .... more work inside the transaction ...
    future { new MyEntity("Pierre") }
    .... more work inside the transaction ...
  } 

I don't know if it's really that OK nor if a rollback would work (have to test it) but it's the only solution I found to create a new Entity inside the asyncTransaction.

Maybe the doc should explain this (maybe I am tired and missed the example too:)

Regards
Laurent

--
You received this message because you are subscribed to the Google Groups "Activate Persistence Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to activate-persistence+unsub...@googlegroups.com.

Laurent Bedubourg

unread,
Dec 13, 2014, 3:32:25 AM12/13/14
to Flavio W. Brasil, activate-p...@googlegroups.com
Hello,

I did a few more tests (playing with undertow) and it occurred to me that there's another thread which calls the future onResult callback.

In fact it looks like the API / driver use the scala future API on top of the java nio Future api. 

If I understood correctly the former uses threads to handle concurrency whereas the later only works with Listeners which are invoked by one nio thread when some data is ready to process.

1/ I am a little bit afraid of the extra complexity of creating threads for each SQL(or other) request/transaction whereas NIO is designed to avoid that. Am I too paranoid ? :)

2/ when I create a new Entity, I imagine that there are database queries triggered by the constructor? Hence the thread is probably locked to await replies. I understood that async API should never lock the current thread. Maybe an Entity factory should be used instead of direct constructor call?

Thank you for your insight.

Best regards
Laurent


To unsubscribe from this group and stop receiving emails from it, send an email to activate-persistence+unsubscrib...@googlegroups.com.

Flavio W. Brasil

unread,
Jan 14, 2015, 3:23:16 PM1/14/15
to Laurent Bedubourg, activate-p...@googlegroups.com
Hey Laurent,

On Saturday, December 13, 2014 at 9:32 AM, Laurent Bedubourg wrote:

Hello,

I did a few more tests (playing with undertow) and it occurred to me that there's another thread which calls the future onResult callback.

In fact it looks like the API / driver use the scala future API on top of the java nio Future api. 

If I understood correctly the former uses threads to handle concurrency whereas the later only works with Listeners which are invoked by one nio thread when some data is ready to process.

1/ I am a little bit afraid of the extra complexity of creating threads for each SQL(or other) request/transaction whereas NIO is designed to avoid that. Am I too paranoid ? :)
It is possible to reuse threads with a thread pool. Activate uses the scala’s default pool, but it is possible to override in you storage definition:


2/ when I create a new Entity, I imagine that there are database queries triggered by the constructor? Hence the thread is probably locked to await replies. I understood that async API should never lock the current thread. Maybe an Entity factory should be used instead of direct constructor call?
Activate runs the entire transaction in-memory, relying on the STM’s transactional guarantees. It goes to the database only if you use an explicit query. If you use the async* methods that Activate provides, there aren’t blocking operations being done. 
Reply all
Reply to author
Forward
0 new messages