You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <ji...@apache.org> on 2008/02/07 08:47:08 UTC
[jira] Created: (DERBY-3396) At the end transaction time(through
commit/rollback), is clearing of the conglomerate (used for scans for
update and delete) for an activation happening in the right place?
At the end transaction time(through commit/rollback), is clearing of the conglomerate (used for scans for update and delete) for an activation happening in the right place?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-3396
URL: https://issues.apache.org/jira/browse/DERBY-3396
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Mamta A. Satoor
This is a fallout from DERBY-3304 https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566169#action_12566169 (Dan's comment "For the update conglomerate clearing, I think that's code that is in the wrong location, probably should be in the result set that set that field. That's probably a separate issue.")
At the time of commit processing, GenericLangaugeConnectionContext.endTransactionActivationHandling does following
a.clearHeapConglomerateController();
At the time of rollback processing, BaseActivation.reset() does following
updateHeapCC = null;
Seems like the code for clearing conglomerate should be in a different place. I haven't done research myself but wanted to log it as a jira entry so we do not forget about it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3396) At the end transaction time(through
commit/rollback), is clearing of the conglomerate (used for scans for
update and delete) for an activation happening in the right place?
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-3396:
------------------------------------
Urgency: Normal
Triaged for 10.5.2.
Assigned normal urgency.
> At the end transaction time(through commit/rollback), is clearing of the conglomerate (used for scans for update and delete) for an activation happening in the right place?
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3396
> URL: https://issues.apache.org/jira/browse/DERBY-3396
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Reporter: Mamta A. Satoor
>
> This is a fallout from DERBY-3304 https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566169#action_12566169 (Dan's comment "For the update conglomerate clearing, I think that's code that is in the wrong location, probably should be in the result set that set that field. That's probably a separate issue.")
> At the time of commit processing, GenericLangaugeConnectionContext.endTransactionActivationHandling does following
> a.clearHeapConglomerateController();
> At the time of rollback processing, BaseActivation.reset() does following
> updateHeapCC = null;
> Seems like the code for clearing conglomerate should be in a different place. I haven't done research myself but wanted to log it as a jira entry so we do not forget about it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.