null entity vars after initialization about activate HOT 5 CLOSED

Hi Grant.

The transaction control is done using a ThreadLocal. Actors normally runs in another thread, so maybe this is the problem.

In your example, the Actor message is sent inside of the transactional block that creates the entity. If the message is received before the end of the transaction, the entity will be empty to the Actor.

Try to review the transaction demarcation of your application. As a general rule, is not good to send messages to Actors inside transactional blocks.

from activate.

In my actual app I was not purposefully sending messages inside a transaction (although my messages are idempotent so I suppose it wouldn't break anything).

However the problematic code was being executing as part of an object's initializtion. This must have sometimes been run inside the context of another transaction, because when I explicitly initialize the object during application start, the errors go away.

In hindsight the problem is pretty obvious, but I didn't know there was a transaction running in the current thread. It would be great if there was an explicit error message when this occurs. The one thing I miss from Slick is its implicit / type-checked transactions.

Anyway, thanks. This one had me pretty frustrated.

from activate.

Would transactional(requiresNew) be the right thing to use when you don't know if a another transaction might be in the thread's scope?

from activate.

Is is possible to use a normal transactional{ }, since it uses the required propagation by default. The propagation will create a new transaction if needed. Take a look at:

http://activate-framework.org/documentation/transaction/#propagations

The ThreadLocal approach allows to write code without having to receive the implicit transaction on each method that uses persistence. I consider this approach better, since it avoids boilerplate code and makes the persistence more transparent to the business code.

About the message send inside normal transactional blocks. It must be avoided because it is a side effect. If the STM transaction retries, the message will be sent again. An alternative is to use the "manual" transaction control if you have side effects:

http://activate-framework.org/documentation/transaction/#manual_transaction_control

Remember that with this kind of transactional block, the STM does not retry the transaction and can throw a ConcurrentTransactionException.

Please, confirm if I can close the issue.

Regards,

Flavio

from activate.

Yes, close away and thanks for the help.

from activate.