Quote Originally Posted by tnabil View Post
Thanks, Peter; I just saw your response.

I think it could be that we are not on the same page when it comes to the definition of a transaction in this particular context.

In this context, when I say a statement executed against the DB is not done within a transaction, I mean that the connection used to execute it is in auto-commit mode.
Agreed.

Quote Originally Posted by tnabil View Post
If not, and a sequence of statements are executed together and then the connection is committed (assuming JTA is not involved), then I consider that to be done witihin a transaction.

So, if that's the case, then my understanding is that if a service class is used with transaction demarcation done around its methods, then a transaction will start at the beginning of the service method and end at its end.
This is how transactional services work, yes. Of course, you can explicitly start a transaction before the service method is called, in which case the service method joins that transaction by default. Another subtlety, but probably not relevant here.

Quote Originally Posted by tnabil View Post
Any statements executed before the service method starts will be committed when it starts (just assuming).
I'm not sure this is the case. No guarantees are made about when those changes will be flushed to the database other than they will be flushed no later than when the transaction is committed. But it's generally a Bad Idea to make changes before or after a transaction, particularly before.

Quote Originally Posted by tnabil View Post
Any statements executed after the service method ends will be committed when the response is returned to the client (because the session is closed).
Unless you explicitly flush the session, this is correct. Remember that you can force a flush at any time.