On Tue, Oct 15, 2013 at 12:00 PM, Marina Vatkina
<marina.vatkina_at_oracle.com>wrote:
> Transaction started by a web component is rolled back by the container
> according to the Java EE or a Servlet spec - you can search for the exact
> place and words.
>
Well, it's in EE.4.2.2. of J2EE v7. They say that the behavior of a
transaction is unspecified once the servlet's service() method is done.
They also say that transaction should definitely not be extended beyond
your last filter, even if it's explicitly demarcated.
A spec is a spec, but I do find it a bit unreasonable, considering that
since application's absolute request boundary is the request listener, that
should be included within absolute boundaries of a transaction. It is a
surprise to me, however, that other application servers apparently do
extend that boundary.
>
>
> -marina
>
>
> On 10/15/13 11:51 AM, Pawel Veselov wrote:
>
> On Tue, Oct 15, 2013 at 10:51 AM, Pawel Veselov <pawel.veselov_at_gmail.com>wrote:
>
>> Hi.
>>
>>
>> [skipped]
>
>> Is there a way to tell GlassFish to never automatically manage XA
>> connections from any given XA pool, and let application explicitly commit
>> or roll it back in all cases?
>>
>>
>>
>
> Reading the source, it doesn't look like it's possible. I'm not sure
> this is correct, but JTA spec is not exact on this subject.
> J2EEInstanceListener calls TransactionManager.rollback() unconditionally
> (as long as there is a present transaction) at the end of any "top level
> invocation". This happens before the request listeners are invoked, but
> after all the application-level filters.
>
> So my solution, is to move the finalization code into a filter, and make
> sure this filter is invoked first, and on any request.
>
>
>
--
With best of best regards
Pawel S. Veselov