[ 
https://issues.apache.org/jira/browse/DERBY-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dyre Tjeldvoll reassigned DERBY-6082:
-------------------------------------

    Assignee: Dyre Tjeldvoll

> Investigate if openOnServer_ field in org.apache.derby.client.am.Statement is 
> still needed.
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6082
>                 URL: https://issues.apache.org/jira/browse/DERBY-6082
>             Project: Derby
>          Issue Type: Task
>          Components: Network Client
>    Affects Versions: 10.10.1.1
>            Reporter: Mamta A. Satoor
>            Assignee: Dyre Tjeldvoll
>
> While working on DERBY-6053, there was some discussion over openOnServer_ 
> field in org.apache.derby.client.am.Statement. This field has following 
> comment in Statement class
>     // This means a DERBY server-side section for this statement is in the 
> prepared state. 
>     // A client-side jdbc statement may remain open across commits 
> (openOnClient=true), 
>     // but the server-side DERBY section moves to an unprepared state 
> (openOnServer=false) across commits, 
>     // requiring an implicit re-prepare "under the covers" by the driver. 
>     // Unprepared jdbc query statements still have prepared sections on the 
> server. 
>     // This openOnServer_ only has implications for preparedstatement 
> Kathey commented following on that field in DERBY-6053
> *******************************************************************************
>  I do not think that comment is true about statements not staying prepared 
> across commits.
> If I prepare a statement and execute it twice with a commit in between from 
> client, I do not see a reprepare in the derby.log . I think maybe the 
> openOnServer_ property may be a relic of some place or time in the original 
> code base when that was true.
> *******************************************************************************



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to