Re: [jbosscache-dev] JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
9:54 a.m.
On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
Manik Surtani wrote:
> Sorry about the slow response on this.
> While making JBC an XA resource is on the roadmap, it isn't
> something scheduled for any imminent release [1], as this is a
> pretty big change for the JBC codebase (and more importantly, a
> big feature change which would involve a lot of compatibility
> testing).
> For the time being, treating STATUS_UNKNOWN as a rollback would
> help, but only provided the database (and any other resources
> participating in the tx) has rolled back as well. Jonathan,
> correct me if I am wrong, but there is no way to know this unless
> we are an XA resource as well, am I right?
Actually in heuristic outcomes you still won't necessarily know
what the db did. The transaction manger will tell you what it
decided, but not what each individual resource actually did. For
that you would need JBossTS specific code rather than general
XAResource code. You can partially address that by making the cache
the last resource but you won't eliminate it entirely.
> So is it reasonable to treat a STATUS_UNKNOWN as a rollback, and
> document this limitation, until JBCACHE-70?
yes, or toss anything that is affected out of the cache and let it
be reread from the db on the next tx, which would prevent you ever
getting out of sync. Or course that assumes the data is backed by
some store e.g. the db, which is the case only for EJBs. General
purpose use of the cache is a more difficult case.
Perhaps a switch for this behaviour? By default, do a rollback,
unless -Dorg.jboss.cache.tx.heuristic_outcome_purge = true?
What do you guys think?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
10:10 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Manik Surtani wrote:
On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
> Manik Surtani wrote:
>> Sorry about the slow response on this.
>> While making JBC an XA resource is on the roadmap, it isn't something
>> scheduled for any imminent release [1], as this is a pretty big
>> change for the JBC codebase (and more importantly, a big feature
>> change which would involve a lot of compatibility testing).
>> For the time being, treating STATUS_UNKNOWN as a rollback would help,
>> but only provided the database (and any other resources participating
>> in the tx) has rolled back as well. Jonathan, correct me if I am
>> wrong, but there is no way to know this unless we are an XA resource
>> as well, am I right?
>
> Actually in heuristic outcomes you still won't necessarily know what
> the db did. The transaction manger will tell you what it decided, but
> not what each individual resource actually did. For that you would
> need JBossTS specific code rather than general XAResource code. You
> can partially address that by making the cache the last resource but
> you won't eliminate it entirely.
>
>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback, and
>> document this limitation, until JBCACHE-70?
>
> yes, or toss anything that is affected out of the cache and let it be
> reread from the db on the next tx, which would prevent you ever
> getting out of sync. Or course that assumes the data is backed by some
> store e.g. the db, which is the case only for EJBs. General purpose
> use of the cache is a more difficult case.
Perhaps a switch for this behaviour? By default, do a rollback, unless
-Dorg.jboss.cache.tx.heuristic_outcome_purge = true?
By purge, you mean?
- rollback modifications
- and commit the tx
What do you guys think?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
10:23 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
No - by purge, I mean remove all affected nodes from the cache,
thereby assuming that the cache is backed by a DB and will be
populated again.
On 21 Aug 2007, at 16:10, Galder Zamarreno wrote:
Manik Surtani wrote:
> On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
>> Manik Surtani wrote:
>>> Sorry about the slow response on this.
>>> While making JBC an XA resource is on the roadmap, it isn't
>>> something scheduled for any imminent release [1], as this is a
>>> pretty big change for the JBC codebase (and more importantly, a
>>> big feature change which would involve a lot of compatibility
>>> testing).
>>> For the time being, treating STATUS_UNKNOWN as a rollback would
>>> help, but only provided the database (and any other resources
>>> participating in the tx) has rolled back as well. Jonathan,
>>> correct me if I am wrong, but there is no way to know this
>>> unless we are an XA resource as well, am I right?
>>
>> Actually in heuristic outcomes you still won't necessarily know
>> what the db did. The transaction manger will tell you what it
>> decided, but not what each individual resource actually did. For
>> that you would need JBossTS specific code rather than general
>> XAResource code. You can partially address that by making the
>> cache the last resource but you won't eliminate it entirely.
>>
>>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback, and
>>> document this limitation, until JBCACHE-70?
>>
>> yes, or toss anything that is affected out of the cache and let
>> it be reread from the db on the next tx, which would prevent you
>> ever getting out of sync. Or course that assumes the data is
>> backed by some store e.g. the db, which is the case only for
>> EJBs. General purpose use of the cache is a more difficult case.
> Perhaps a switch for this behaviour? By default, do a rollback,
> unless -Dorg.jboss.cache.tx.heuristic_outcome_purge = true?
By purge, you mean?
- rollback modifications
- and commit the tx
> What do you guys think?
> Cheers,
> --
> Manik Surtani
> Lead, JBoss Cache
> JBoss, a division of Red Hat
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
10:37 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Manik Surtani wrote:
No - by purge, I mean remove all affected nodes from the cache,
thereby
assuming that the cache is backed by a DB and will be populated again.
Ok, I understood now. Sounds like a good solution but not sure whether
it should be configured via a system property. Bearing in mind that
there can be several JBC instances running in AS, do we want to make
this a global thing for all of them? Some of these instances might have
DBs in the back, i.e. HB 2nd level cache (which is the customer's use
case) or not, as in the HTTP session repl cache.
A workaround like this could work thought:
-D<cache_instance_name>.tx.heuristic_outcome_purge = true
Thoughts?
On 21 Aug 2007, at 16:10, Galder Zamarreno wrote:
>
>
> Manik Surtani wrote:
>> On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
>>> Manik Surtani wrote:
>>>> Sorry about the slow response on this.
>>>> While making JBC an XA resource is on the roadmap, it isn't
>>>> something scheduled for any imminent release [1], as this is a
>>>> pretty big change for the JBC codebase (and more importantly, a big
>>>> feature change which would involve a lot of compatibility testing).
>>>> For the time being, treating STATUS_UNKNOWN as a rollback would
>>>> help, but only provided the database (and any other resources
>>>> participating in the tx) has rolled back as well. Jonathan,
>>>> correct me if I am wrong, but there is no way to know this unless
>>>> we are an XA resource as well, am I right?
>>>
>>> Actually in heuristic outcomes you still won't necessarily know what
>>> the db did. The transaction manger will tell you what it decided,
>>> but not what each individual resource actually did. For that you
>>> would need JBossTS specific code rather than general XAResource
>>> code. You can partially address that by making the cache the last
>>> resource but you won't eliminate it entirely.
>>>
>>>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback, and
>>>> document this limitation, until JBCACHE-70?
>>>
>>> yes, or toss anything that is affected out of the cache and let it
>>> be reread from the db on the next tx, which would prevent you ever
>>> getting out of sync. Or course that assumes the data is backed by
>>> some store e.g. the db, which is the case only for EJBs. General
>>> purpose use of the cache is a more difficult case.
>> Perhaps a switch for this behaviour? By default, do a rollback,
>> unless -Dorg.jboss.cache.tx.heuristic_outcome_purge = true?
>
> By purge, you mean?
> - rollback modifications
> - and commit the tx
>
>> What do you guys think?
>> Cheers,
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>
> --
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
10:47 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Or just a configuration entry. :-) I just don't like introducing
config entries in SPs.
On 21 Aug 2007, at 16:37, Galder Zamarreno wrote:
Manik Surtani wrote:
> No - by purge, I mean remove all affected nodes from the cache,
> thereby assuming that the cache is backed by a DB and will be
> populated again.
Ok, I understood now. Sounds like a good solution but not sure
whether it should be configured via a system property. Bearing in
mind that there can be several JBC instances running in AS, do we
want to make this a global thing for all of them? Some of these
instances might have DBs in the back, i.e. HB 2nd level cache
(which is the customer's use case) or not, as in the HTTP session
repl cache.
A workaround like this could work thought:
-D<cache_instance_name>.tx.heuristic_outcome_purge = true
Thoughts?
> On 21 Aug 2007, at 16:10, Galder Zamarreno wrote:
>>
>>
>> Manik Surtani wrote:
>>> On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
>>>> Manik Surtani wrote:
>>>>> Sorry about the slow response on this.
>>>>> While making JBC an XA resource is on the roadmap, it isn't
>>>>> something scheduled for any imminent release [1], as this is a
>>>>> pretty big change for the JBC codebase (and more importantly,
>>>>> a big feature change which would involve a lot of
>>>>> compatibility testing).
>>>>> For the time being, treating STATUS_UNKNOWN as a rollback
>>>>> would help, but only provided the database (and any other
>>>>> resources participating in the tx) has rolled back as well.
>>>>> Jonathan, correct me if I am wrong, but there is no way to
>>>>> know this unless we are an XA resource as well, am I right?
>>>>
>>>> Actually in heuristic outcomes you still won't necessarily know
>>>> what the db did. The transaction manger will tell you what it
>>>> decided, but not what each individual resource actually did.
>>>> For that you would need JBossTS specific code rather than
>>>> general XAResource code. You can partially address that by
>>>> making the cache the last resource but you won't eliminate it
>>>> entirely.
>>>>
>>>>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback,
>>>>> and document this limitation, until JBCACHE-70?
>>>>
>>>> yes, or toss anything that is affected out of the cache and let
>>>> it be reread from the db on the next tx, which would prevent
>>>> you ever getting out of sync. Or course that assumes the data
>>>> is backed by some store e.g. the db, which is the case only for
>>>> EJBs. General purpose use of the cache is a more difficult case.
>>> Perhaps a switch for this behaviour? By default, do a rollback,
>>> unless -Dorg.jboss.cache.tx.heuristic_outcome_purge = true?
>>
>> By purge, you mean?
>> - rollback modifications
>> - and commit the tx
>>
>>> What do you guys think?
>>> Cheers,
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>
>> --
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
> --
> Manik Surtani
> Lead, JBoss Cache
> JBoss, a division of Red Hat
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
11:31 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Ok, I just spoke to Steve @ Hibernate on how Hibernate deals with
this situation. From an IM conversation:
"that is deemed a failed transaction
anything other than committed"
So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
therefore a safe default.
Is there a good reason to try and purge the nodes in such a case? Or
just stick with the default above?
On 21 Aug 2007, at 16:47, Manik Surtani wrote:
Or just a configuration entry. :-) I just don't like
introducing
config entries in SPs.
On 21 Aug 2007, at 16:37, Galder Zamarreno wrote:
>
>
> Manik Surtani wrote:
>> No - by purge, I mean remove all affected nodes from the cache,
>> thereby assuming that the cache is backed by a DB and will be
>> populated again.
>
> Ok, I understood now. Sounds like a good solution but not sure
> whether it should be configured via a system property. Bearing in
> mind that there can be several JBC instances running in AS, do we
> want to make this a global thing for all of them? Some of these
> instances might have DBs in the back, i.e. HB 2nd level cache
> (which is the customer's use case) or not, as in the HTTP session
> repl cache.
>
> A workaround like this could work thought:
>
> -D<cache_instance_name>.tx.heuristic_outcome_purge = true
>
> Thoughts?
>> On 21 Aug 2007, at 16:10, Galder Zamarreno wrote:
>>>
>>>
>>> Manik Surtani wrote:
>>>> On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
>>>>> Manik Surtani wrote:
>>>>>> Sorry about the slow response on this.
>>>>>> While making JBC an XA resource is on the roadmap, it isn't
>>>>>> something scheduled for any imminent release [1], as this is
>>>>>> a pretty big change for the JBC codebase (and more
>>>>>> importantly, a big feature change which would involve a lot
>>>>>> of compatibility testing).
>>>>>> For the time being, treating STATUS_UNKNOWN as a rollback
>>>>>> would help, but only provided the database (and any other
>>>>>> resources participating in the tx) has rolled back as well.
>>>>>> Jonathan, correct me if I am wrong, but there is no way to
>>>>>> know this unless we are an XA resource as well, am I right?
>>>>>
>>>>> Actually in heuristic outcomes you still won't necessarily
>>>>> know what the db did. The transaction manger will tell you
>>>>> what it decided, but not what each individual resource
>>>>> actually did. For that you would need JBossTS specific code
>>>>> rather than general XAResource code. You can partially address
>>>>> that by making the cache the last resource but you won't
>>>>> eliminate it entirely.
>>>>>
>>>>>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback,
>>>>>> and document this limitation, until JBCACHE-70?
>>>>>
>>>>> yes, or toss anything that is affected out of the cache and
>>>>> let it be reread from the db on the next tx, which would
>>>>> prevent you ever getting out of sync. Or course that assumes
>>>>> the data is backed by some store e.g. the db, which is the
>>>>> case only for EJBs. General purpose use of the cache is a more
>>>>> difficult case.
>>>> Perhaps a switch for this behaviour? By default, do a
>>>> rollback, unless -Dorg.jboss.cache.tx.heuristic_outcome_purge =
>>>> true?
>>>
>>> By purge, you mean?
>>> - rollback modifications
>>> - and commit the tx
>>>
>>>> What do you guys think?
>>>> Cheers,
>>>> --
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> JBoss, a division of Red Hat
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>
> --
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
1:01 p.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Manik Surtani wrote:
Ok, I just spoke to Steve @ Hibernate on how Hibernate deals with
this
situation. From an IM conversation:
"that is deemed a failed transaction
anything other than committed"
So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
therefore a safe default.
Is there a good reason to try and purge the nodes in such a case? Or
just stick with the default above?
I think this makes more sense for the cache controlling application to
be responsible for removing data. If you look at the hibernate case it
does stuff outside the realm of the tx boundary anyway
(putForExternalRead). So even if we did auto purge, it's not guaranteed
that we are purging the correct data.
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
5:26 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
+1. So the controlling app - which would typically be a participant
in the tx anyway - would react to a STATUS_UNKNOWN by clearing the
cache of the nodes involved. The cache itself just treats
STATUS_UNKNOWN as a rollback.
On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
Manik Surtani wrote:
> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals with
> this situation. From an IM conversation:
> "that is deemed a failed transaction
> anything other than committed"
> So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
> therefore a safe default.
> Is there a good reason to try and purge the nodes in such a case?
> Or just stick with the default above?
I think this makes more sense for the cache controlling application
to be responsible for removing data. If you look at the hibernate
case it does stuff outside the realm of the tx boundary anyway
(putForExternalRead). So even if we did auto purge, it's not
guaranteed that we are purging the correct data.
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
5:33 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
The client app will actually get a heuristic exception in
response to its commit call and should do cleanup in the
exception handler. However, that's not always going to be
user code, it may be e.g. the app server's EJB container in
the case of CMT. Hence if you go down this route, which I
agree is probably the best approach, other parts of the app
server may need to be aware of the issues.
Jonathan.
Manik Surtani wrote:
+1. So the controlling app - which would typically be a participant
in
the tx anyway - would react to a STATUS_UNKNOWN by clearing the cache of
the nodes involved. The cache itself just treats STATUS_UNKNOWN as a
rollback.
On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
> Manik Surtani wrote:
>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals with
>> this situation. From an IM conversation:
>> "that is deemed a failed transaction
>> anything other than committed"
>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
>> therefore a safe default.
>> Is there a good reason to try and purge the nodes in such a case? Or
>> just stick with the default above?
>
> I think this makes more sense for the cache controlling application to
> be responsible for removing data. If you look at the hibernate case it
> does stuff outside the realm of the tx boundary anyway
> (putForExternalRead). So even if we did auto purge, it's not
> guaranteed that we are purging the correct data.
>
> --
> Jason T. Greene
> Lead, POJO Cache
> JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
------------------------------------------------------------
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No.
3798903 Directors: Michael Cunningham (USA), Charlie Peters
(USA) and David Owens (Ireland)
6 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Sure. I suspect they would already deal with this in such a manner
anyway, given that this is how Hibernate deals with STATUS_UNKNOWN.
On 22 Aug 2007, at 11:33, Jonathan Halliday wrote:
The client app will actually get a heuristic exception in response
to its commit call and should do cleanup in the exception handler.
However, that's not always going to be user code, it may be e.g.
the app server's EJB container in the case of CMT. Hence if you go
down this route, which I agree is probably the best approach, other
parts of the app server may need to be aware of the issues.
Jonathan.
Manik Surtani wrote:
> +1. So the controlling app - which would typically be a
> participant in the tx anyway - would react to a STATUS_UNKNOWN by
> clearing the cache of the nodes involved. The cache itself just
> treats STATUS_UNKNOWN as a rollback.
> On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
>> Manik Surtani wrote:
>>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals
>>> with this situation. From an IM conversation:
>>> "that is deemed a failed transaction
>>> anything other than committed"
>>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
>>> therefore a safe default.
>>> Is there a good reason to try and purge the nodes in such a
>>> case? Or just stick with the default above?
>>
>> I think this makes more sense for the cache controlling
>> application to be responsible for removing data. If you look at
>> the hibernate case it does stuff outside the realm of the tx
>> boundary anyway (putForExternalRead). So even if we did auto
>> purge, it's not guaranteed that we are purging the correct data.
>>
>> --
>> Jason T. Greene
>> Lead, POJO Cache
>> JBoss, a division of Red Hat
> --
> Manik Surtani
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
------------------------------------------------------------
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
11:51 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Ok, so here is the fix I propose.
Index: TxInterceptor.java
===================================================================
--- TxInterceptor.java (revision 4310)
+++ TxInterceptor.java (revision 4311)
@@ -1076,7 +1076,8 @@
runCommitPhase(gtx, tx, modifications,
onePhaseCommit);
log.debug("Finished commit phase");
break;
-
+ case Status.STATUS_UNKNOWN:
+ log.warn("Received JTA STATUS_UNKNOWN in
afterCompletion()! XA resources may not be in sync. The app should
manually clean up resources at this point.");
case Status.STATUS_MARKED_ROLLBACK:
case Status.STATUS_ROLLEDBACK:
log.debug("Running rollback phase");
Log a warning and then treat as a rollback.
Does this make sense?
On 22 Aug 2007, at 12:00, Manik Surtani wrote:
Sure. I suspect they would already deal with this in such a manner
anyway, given that this is how Hibernate deals with STATUS_UNKNOWN.
On 22 Aug 2007, at 11:33, Jonathan Halliday wrote:
>
> The client app will actually get a heuristic exception in response
> to its commit call and should do cleanup in the exception handler.
> However, that's not always going to be user code, it may be e.g.
> the app server's EJB container in the case of CMT. Hence if you go
> down this route, which I agree is probably the best approach,
> other parts of the app server may need to be aware of the issues.
>
> Jonathan.
>
> Manik Surtani wrote:
>> +1. So the controlling app - which would typically be a
>> participant in the tx anyway - would react to a STATUS_UNKNOWN by
>> clearing the cache of the nodes involved. The cache itself just
>> treats STATUS_UNKNOWN as a rollback.
>> On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
>>> Manik Surtani wrote:
>>>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals
>>>> with this situation. From an IM conversation:
>>>> "that is deemed a failed transaction
>>>> anything other than committed"
>>>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this
>>>> is therefore a safe default.
>>>> Is there a good reason to try and purge the nodes in such a
>>>> case? Or just stick with the default above?
>>>
>>> I think this makes more sense for the cache controlling
>>> application to be responsible for removing data. If you look at
>>> the hibernate case it does stuff outside the realm of the tx
>>> boundary anyway (putForExternalRead). So even if we did auto
>>> purge, it's not guaranteed that we are purging the correct data.
>>>
>>> --
>>> Jason T. Greene
>>> Lead, POJO Cache
>>> JBoss, a division of Red Hat
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
> --
> ------------------------------------------------------------
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA) and
> David Owens (Ireland)
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
9:21 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Jonathan,
If you reckon this works, let me know and I'll go ahead and confirm
the fix. It is checked in to SVN:
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/
tests/functional/org/jboss/cache/transaction/StatusUnknownTest.java
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/src/
org/jboss/cache/interceptors/TxInterceptor.java
Cheers,
Manik
On 23 Aug 2007, at 17:51, Manik Surtani wrote:
Ok, so here is the fix I propose.
Index: TxInterceptor.java
===================================================================
--- TxInterceptor.java (revision 4310)
+++ TxInterceptor.java (revision 4311)
@@ -1076,7 +1076,8 @@
runCommitPhase(gtx, tx, modifications,
onePhaseCommit);
log.debug("Finished commit phase");
break;
-
+ case Status.STATUS_UNKNOWN:
+ log.warn("Received JTA STATUS_UNKNOWN in
afterCompletion()! XA resources may not be in sync. The app
should manually clean up resources at this point.");
case Status.STATUS_MARKED_ROLLBACK:
case Status.STATUS_ROLLEDBACK:
log.debug("Running rollback phase");
Log a warning and then treat as a rollback.
Does this make sense?
On 22 Aug 2007, at 12:00, Manik Surtani wrote:
> Sure. I suspect they would already deal with this in such a
> manner anyway, given that this is how Hibernate deals with
> STATUS_UNKNOWN.
>
>
> On 22 Aug 2007, at 11:33, Jonathan Halliday wrote:
>
>>
>> The client app will actually get a heuristic exception in
>> response to its commit call and should do cleanup in the
>> exception handler. However, that's not always going to be user
>> code, it may be e.g. the app server's EJB container in the case
>> of CMT. Hence if you go down this route, which I agree is
>> probably the best approach, other parts of the app server may
>> need to be aware of the issues.
>>
>> Jonathan.
>>
>> Manik Surtani wrote:
>>> +1. So the controlling app - which would typically be a
>>> participant in the tx anyway - would react to a STATUS_UNKNOWN
>>> by clearing the cache of the nodes involved. The cache itself
>>> just treats STATUS_UNKNOWN as a rollback.
>>> On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
>>>> Manik Surtani wrote:
>>>>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals
>>>>> with this situation. From an IM conversation:
>>>>> "that is deemed a failed transaction
>>>>> anything other than committed"
>>>>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this
>>>>> is therefore a safe default.
>>>>> Is there a good reason to try and purge the nodes in such a
>>>>> case? Or just stick with the default above?
>>>>
>>>> I think this makes more sense for the cache controlling
>>>> application to be responsible for removing data. If you look at
>>>> the hibernate case it does stuff outside the realm of the tx
>>>> boundary anyway (putForExternalRead). So even if we did auto
>>>> purge, it's not guaranteed that we are purging the correct data.
>>>>
>>>> --
>>>> Jason T. Greene
>>>> Lead, POJO Cache
>>>> JBoss, a division of Red Hat
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>> --
>> ------------------------------------------------------------
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
>> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No.
>> 3798903 Directors: Michael Cunningham (USA), Charlie Peters
>> (USA) and David Owens (Ireland)
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
9:29 a.m.
New subject: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]
Yep that looks good.
Jonathan.
Manik Surtani wrote:
Jonathan,
If you reckon this works, let me know and I'll go ahead and confirm the
fix. It is checked in to SVN:
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/tests/fu...
http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/src/org/...
Cheers,
Manik
On 23 Aug 2007, at 17:51, Manik Surtani wrote:
> Ok, so here is the fix I propose.
>
> Index: TxInterceptor.java
> ===================================================================
> --- TxInterceptor.java (revision 4310)
> +++ TxInterceptor.java (revision 4311)
> @@ -1076,7 +1076,8 @@
> runCommitPhase(gtx, tx, modifications,
> onePhaseCommit);
> log.debug("Finished commit phase");
> break;
> -
> + case Status.STATUS_UNKNOWN:
> + log.warn("Received JTA STATUS_UNKNOWN in
> afterCompletion()! XA resources may not be in sync. The app should
> manually clean up resources at this point.");
> case Status.STATUS_MARKED_ROLLBACK:
> case Status.STATUS_ROLLEDBACK:
> log.debug("Running rollback phase");
>
> Log a warning and then treat as a rollback.
>
> Does this make sense?
>
>
> On 22 Aug 2007, at 12:00, Manik Surtani wrote:
>
>> Sure. I suspect they would already deal with this in such a manner
>> anyway, given that this is how Hibernate deals with STATUS_UNKNOWN.
>>
>>
>> On 22 Aug 2007, at 11:33, Jonathan Halliday wrote:
>>
>>>
>>> The client app will actually get a heuristic exception in response
>>> to its commit call and should do cleanup in the exception handler.
>>> However, that's not always going to be user code, it may be e.g. the
>>> app server's EJB container in the case of CMT. Hence if you go down
>>> this route, which I agree is probably the best approach, other parts
>>> of the app server may need to be aware of the issues.
>>>
>>> Jonathan.
>>>
>>> Manik Surtani wrote:
>>>> +1. So the controlling app - which would typically be a
>>>> participant in the tx anyway - would react to a STATUS_UNKNOWN by
>>>> clearing the cache of the nodes involved. The cache itself just
>>>> treats STATUS_UNKNOWN as a rollback.
>>>> On 21 Aug 2007, at 19:01, Jason T. Greene wrote:
>>>>> Manik Surtani wrote:
>>>>>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals with
>>>>>> this situation. From an IM conversation:
>>>>>> "that is deemed a failed transaction
>>>>>> anything other than committed"
>>>>>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this is
>>>>>> therefore a safe default.
>>>>>> Is there a good reason to try and purge the nodes in such a
>>>>>> case? Or just stick with the default above?
>>>>>
>>>>> I think this makes more sense for the cache controlling
>>>>> application to be responsible for removing data. If you look at
>>>>> the hibernate case it does stuff outside the realm of the tx
>>>>> boundary anyway (putForExternalRead). So even if we did auto
>>>>> purge, it's not guaranteed that we are purging the correct data.
>>>>>
>>>>> --
>>>>> Jason T. Greene
>>>>> Lead, POJO Cache
>>>>> JBoss, a division of Red Hat
>>>> --
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> jbosscache-dev mailing list
>>>> jbosscache-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903
>>> Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
>>> Owens (Ireland)
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
>
>
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
--
------------------------------------------------------------
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No.
3798903 Directors: Michael Cunningham (USA), Charlie Peters
(USA) and David Owens (Ireland)
6300
days inactive
6303
days old
jbosscache-dev@lists.jboss.org
12 comments
4 participants
participants (4)
-
Galder Zamarreno -
Jason T. Greene -
Jonathan Halliday -
Manik Surtani