[JIRA] Updated: (NXP-7943) Fix Oracle tightly-coupled transaction optimization XA bug
[
https://jira.nuxeo.com/browse/NXP-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Guillaume updated NXP-7943:
---
Affects Version/s: (was: 5.5-SNAPSHOT)
5.3 GA
> Fix Oracle tightly-coupled transaction optimization XA bug
> --
>
> Key: NXP-7943
> URL: https://jira.nuxeo.com/browse/NXP-7943
> Project: Nuxeo Enterprise Platform
> Issue Type: Bug
> Components: Core SQL Storage
>Affects Versions: 5.3 GA
>Reporter: Florent Guillaume
>Assignee: Florent Guillaume
>Priority: Major
> Fix For: 5.5
>
>
> When using XA with more than one resource, Oracle by default uses a
> "tightly-coupled transaction" mode for the various transaction branches of
> the resources. In this mode, all the resources except the last one return
> {{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource
> does {{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}.
> This is likely done to avoid doing one more round-trip to the database per
> resource.
> However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
> necessarily mean that no work was done by the resource, so there may still be
> invalidations that have to be sent.
> See
> http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
> for reference.
> A consequence of not sending invalidations is that data may appear
> inconsistent between two session.
> Note that this bug only happens with two or more XA resources, which can only
> be the case with two or more VCS repositories, or a VCS repository and a XA
> JDBC datasource.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
ECM-tickets mailing list
ECM-tickets@lists.nuxeo.com
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
[JIRA] Updated: (NXP-7943) Fix Oracle tightly-coupled transaction optimization XA bug
[
https://jira.nuxeo.com/browse/NXP-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thierry Martins updated NXP-7943:
-
Tags: 542-hf14
> Fix Oracle tightly-coupled transaction optimization XA bug
> --
>
> Key: NXP-7943
> URL: https://jira.nuxeo.com/browse/NXP-7943
> Project: Nuxeo Enterprise Platform
> Issue Type: Bug
> Components: Core SQL Storage
>Affects Versions: 5.5-SNAPSHOT
>Reporter: Florent Guillaume
>Assignee: Florent Guillaume
>Priority: Major
> Fix For: 5.5
>
>
> When using XA with more than one resource, Oracle by default uses a
> "tightly-coupled transaction" mode for the various transaction branches of
> the resources. In this mode, all the resources except the last one return
> {{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource
> does {{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}.
> This is likely done to avoid doing one more round-trip to the database per
> resource.
> However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
> necessarily mean that no work was done by the resource, so there may still be
> invalidations that have to be sent.
> See
> http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
> for reference.
> A consequence of not sending invalidations is that data may appear
> inconsistent between two session.
> Note that this bug only happens with two or more XA resources, which can only
> be the case with two or more VCS repositories, or a VCS repository and a XA
> JDBC datasource.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
ECM-tickets mailing list
ECM-tickets@lists.nuxeo.com
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
[JIRA] Updated: (NXP-7943) Fix Oracle tightly-coupled transaction optimization XA bug
[
https://jira.nuxeo.com/browse/NXP-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Guillaume updated NXP-7943:
---
Description:
When using XA with more than one resource, Oracle by default uses a
"tightly-coupled transaction" mode for the various transaction branches of the
resources. In this mode, all the resources except the last one return
{{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource does
{{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}. This is
likely done to avoid doing one more round-trip to the database per resource.
However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
necessarily mean that no work was done by the resource, so there may still be
invalidations that have to be sent.
See http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
for reference.
A consequence of not sending invalidations is that data may appear inconsistent
between two session.
Note that this bug only happens with two or more XA resources, which can only
be the case with two or more VCS repositories, or a VCS repository and a XA
JDBC datasource.
was:
When using XA with more than one resource, Oracle by default uses a
"tightly-coupled transaction" mode for the various transaction branches of the
resources. In this mode, all the resources except the last one return
{{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource does
{{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}. This is
likely done to avoid doing one more round-trip to the database per resource.
However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
necessarily mean that no work was done by the resource, so there may still be
invalidations that have to be sent.
See http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
for reference.
> Fix Oracle tightly-coupled transaction optimization XA bug
> --
>
> Key: NXP-7943
> URL: https://jira.nuxeo.com/browse/NXP-7943
> Project: Nuxeo Enterprise Platform
> Issue Type: Bug
> Components: Core SQL Storage
>Affects Versions: 5.5-SNAPSHOT
>Reporter: Florent Guillaume
>Assignee: Florent Guillaume
>Priority: Major
> Fix For: 5.5
>
>
> When using XA with more than one resource, Oracle by default uses a
> "tightly-coupled transaction" mode for the various transaction branches of
> the resources. In this mode, all the resources except the last one return
> {{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource
> does {{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}.
> This is likely done to avoid doing one more round-trip to the database per
> resource.
> However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
> necessarily mean that no work was done by the resource, so there may still be
> invalidations that have to be sent.
> See
> http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
> for reference.
> A consequence of not sending invalidations is that data may appear
> inconsistent between two session.
> Note that this bug only happens with two or more XA resources, which can only
> be the case with two or more VCS repositories, or a VCS repository and a XA
> JDBC datasource.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
ECM-tickets mailing list
ECM-tickets@lists.nuxeo.com
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
[JIRA] Updated: (NXP-7943) Fix Oracle tightly-coupled transaction optimization XA bug
[
https://jira.nuxeo.com/browse/NXP-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Guillaume updated NXP-7943:
---
Status: Open (was: Triage)
> Fix Oracle tightly-coupled transaction optimization XA bug
> --
>
> Key: NXP-7943
> URL: https://jira.nuxeo.com/browse/NXP-7943
> Project: Nuxeo Enterprise Platform
> Issue Type: Bug
> Components: Core SQL Storage
>Affects Versions: 5.5-SNAPSHOT
>Reporter: Florent Guillaume
>Assignee: Florent Guillaume
>Priority: Major
> Fix For: 5.5
>
>
> When using XA with more than one resource, Oracle by default uses a
> "tightly-coupled transaction" mode for the various transaction branches of
> the resources. In this mode, all the resources except the last one return
> {{XA_RDONLY}} when {{prepare()}} is called, and only for the last resource
> does {{prepare()}} return {{XA_OK}} thus triggering the normal {{commit()}}.
> This is likely done to avoid doing one more round-trip to the database per
> resource.
> However it means that receiving {{XA_RDONLY}} from {{prepare()}} does not
> necessarily mean that no work was done by the resource, so there may still be
> invalidations that have to be sent.
> See
> http://docs.oracle.com/cd/E14072_01/appdev.112/e10471/adfns_xa.htm#ADFNS810
> for reference.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
ECM-tickets mailing list
ECM-tickets@lists.nuxeo.com
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
