You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "David Ezzio (JIRA)" <ji...@apache.org> on 2008/02/11 18:26:08 UTC
[jira] Created: (OPENJPA-514) Problems with the
openjpa.RestoreState property
Problems with the openjpa.RestoreState property
-----------------------------------------------
Key: OPENJPA-514
URL: https://issues.apache.org/jira/browse/OPENJPA-514
Project: OpenJPA
Issue Type: Bug
Affects Versions: 1.1.0
Environment: Windows, at OpenJPA revision 619978
Reporter: David Ezzio
Section 3.3.2 of the JPA spec is clear that upon rollback, all managed
instances become detached, and in their detached state they may not be
consistent or reusable as normally detached instances would be.
OpenJPA has a property "openjpa.RestoreState" for which it claims a much
stronger behavior. In section 5.6.1, the OpenJPA manual says:
"While the JPA specification says that you should not use rolled
back objects, such objects are perfectly valid in OpenJPA. You can
control whether the objects' managed state is rolled back to its
pre-transaction values with the openjpa.RestoreState configuration
property. none does not roll back state (the object becomes hollow,
and will re-load its state the next time it is accessed), immutable
restores immutable values (primitives, primitive wrappers, strings)
and clears mutable values so that they are reloaded on next access,
and all restores all managed values to their pre-transaction state."
In section 2.5.53, the OpenJPA manual identifies three values for the
the openjpa.RestoreState value. It identifies "none" as the default
value.
In fact, two central statements in the above cited passages from the
OpenJPA manual are not true. In addition, the behavior in restoring
fields is controlled at least in part by other factors.
To begin with, a detached object will not reload any state. In the
second instance, the default value appears to be "immutable" instead of
"none".
Two test cases were run with the entity class Dohickey. Dohickey has two
string fields, lazy and eager, as well as an integer identity field.
Both test cases use a new entity manager. In the first test case, the
lazy field is dirtied in a newly found a Dohickey. In the second test
case, the lazy field is dirtied after dirtying the eager field in a
newly found Dohickey. In both test cases, the transaction is rolled
back. The detached Dohickey is then tested for detachment, and for
whether the values of the eager and lazy fields match the values in the
database.
Number Test case RestoreState Restored Eager Restored Lazy
------+------------+---------------+--------------+--------------
1 Lazy only undefined db value dirty value
2 Lazy only none null null
3 Lazy only immutable db value dirty value
4 Eager first undefined db value null
5 Eager first none null null
6 Eager first immutable db value null
Test cases 1, 3, 4, and 6 indicate that the default value is likely
"immutable".
Test cases 2 and 5 indicate that the "none" value behaves as described
after correcting the statement that fields will be reloaded.
The test cases indicate that the behavior for "immutable" setting does
not work as expected, since the behavior depends on whether the field is
eagerly or lazily loaded (and perhaps on fetch group configurations as
well.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-514) Problems with the
openjpa.RestoreState property
Posted by "David Ezzio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Ezzio updated OPENJPA-514:
--------------------------------
Attachment: TestCasesOpenJPA-514.zip
Test cases described.
> Problems with the openjpa.RestoreState property
> -----------------------------------------------
>
> Key: OPENJPA-514
> URL: https://issues.apache.org/jira/browse/OPENJPA-514
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.1.0
> Environment: Windows, at OpenJPA revision 619978
> Reporter: David Ezzio
> Attachments: TestCasesOpenJPA-514.zip
>
>
> Section 3.3.2 of the JPA spec is clear that upon rollback, all managed
> instances become detached, and in their detached state they may not be
> consistent or reusable as normally detached instances would be.
> OpenJPA has a property "openjpa.RestoreState" for which it claims a much
> stronger behavior. In section 5.6.1, the OpenJPA manual says:
> "While the JPA specification says that you should not use rolled
> back objects, such objects are perfectly valid in OpenJPA. You can
> control whether the objects' managed state is rolled back to its
> pre-transaction values with the openjpa.RestoreState configuration
> property. none does not roll back state (the object becomes hollow,
> and will re-load its state the next time it is accessed), immutable
> restores immutable values (primitives, primitive wrappers, strings)
> and clears mutable values so that they are reloaded on next access,
> and all restores all managed values to their pre-transaction state."
>
> In section 2.5.53, the OpenJPA manual identifies three values for the
> the openjpa.RestoreState value. It identifies "none" as the default
> value.
> In fact, two central statements in the above cited passages from the
> OpenJPA manual are not true. In addition, the behavior in restoring
> fields is controlled at least in part by other factors.
> To begin with, a detached object will not reload any state. In the
> second instance, the default value appears to be "immutable" instead of
> "none".
> Two test cases were run with the entity class Dohickey. Dohickey has two
> string fields, lazy and eager, as well as an integer identity field.
> Both test cases use a new entity manager. In the first test case, the
> lazy field is dirtied in a newly found a Dohickey. In the second test
> case, the lazy field is dirtied after dirtying the eager field in a
> newly found Dohickey. In both test cases, the transaction is rolled
> back. The detached Dohickey is then tested for detachment, and for
> whether the values of the eager and lazy fields match the values in the
> database.
> Number Test case RestoreState Restored Eager Restored Lazy
> ------+------------+---------------+--------------+--------------
> 1 Lazy only undefined db value dirty value
> 2 Lazy only none null null
> 3 Lazy only immutable db value dirty value
> 4 Eager first undefined db value null
> 5 Eager first none null null
> 6 Eager first immutable db value null
> Test cases 1, 3, 4, and 6 indicate that the default value is likely
> "immutable".
> Test cases 2 and 5 indicate that the "none" value behaves as described
> after correcting the statement that fields will be reloaded.
> The test cases indicate that the behavior for "immutable" setting does
> not work as expected, since the behavior depends on whether the field is
> eagerly or lazily loaded (and perhaps on fetch group configurations as
> well.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-514) Problems with the
openjpa.RestoreState property
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568259#action_12568259 ]
Craig Russell commented on OPENJPA-514:
---------------------------------------
I found that section 5.1 of the latest online manual http://openjpa.apache.org/docs/latest/manual/manual.html describes restoreState behavior.
It sounds from the description like this only applies to non-transaction-scoped (extended) persistence contexts. It talks about instances reloading state from the database, which is only applicable for extended persistence contexts.
I can't think of a good reason to do anything special with transaction-scoped persistence contexts, in which instances are detached at transaction completion.
I'd rewrite the 5.1 to explicitly state that this behavior only applies to extended persistence contexts. And if OpenJPA does anything based on this flag in transaction-scoped persistence contexts, it probably should not.
And one question as to your wording:
>In fact, two central statements in the above cited passages from the OpenJPA manual are not true.
Are you implying that the statements are not true and should be changed, or that the implementation has a bug and the documentation is ok?
> Problems with the openjpa.RestoreState property
> -----------------------------------------------
>
> Key: OPENJPA-514
> URL: https://issues.apache.org/jira/browse/OPENJPA-514
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.1.0
> Environment: Windows, at OpenJPA revision 619978
> Reporter: David Ezzio
> Attachments: TestCasesOpenJPA-514.zip
>
>
> Section 3.3.2 of the JPA spec is clear that upon rollback, all managed
> instances become detached, and in their detached state they may not be
> consistent or reusable as normally detached instances would be.
> OpenJPA has a property "openjpa.RestoreState" for which it claims a much
> stronger behavior. In section 5.6.1, the OpenJPA manual says:
> "While the JPA specification says that you should not use rolled
> back objects, such objects are perfectly valid in OpenJPA. You can
> control whether the objects' managed state is rolled back to its
> pre-transaction values with the openjpa.RestoreState configuration
> property. none does not roll back state (the object becomes hollow,
> and will re-load its state the next time it is accessed), immutable
> restores immutable values (primitives, primitive wrappers, strings)
> and clears mutable values so that they are reloaded on next access,
> and all restores all managed values to their pre-transaction state."
>
> In section 2.5.53, the OpenJPA manual identifies three values for the
> the openjpa.RestoreState value. It identifies "none" as the default
> value.
> In fact, two central statements in the above cited passages from the
> OpenJPA manual are not true. In addition, the behavior in restoring
> fields is controlled at least in part by other factors.
> To begin with, a detached object will not reload any state. In the
> second instance, the default value appears to be "immutable" instead of
> "none".
> Two test cases were run with the entity class Dohickey. Dohickey has two
> string fields, lazy and eager, as well as an integer identity field.
> Both test cases use a new entity manager. In the first test case, the
> lazy field is dirtied in a newly found a Dohickey. In the second test
> case, the lazy field is dirtied after dirtying the eager field in a
> newly found Dohickey. In both test cases, the transaction is rolled
> back. The detached Dohickey is then tested for detachment, and for
> whether the values of the eager and lazy fields match the values in the
> database.
> Number Test case RestoreState Restored Eager Restored Lazy
> ------+------------+---------------+--------------+--------------
> 1 Lazy only undefined db value dirty value
> 2 Lazy only none null null
> 3 Lazy only immutable db value dirty value
> 4 Eager first undefined db value null
> 5 Eager first none null null
> 6 Eager first immutable db value null
> Test cases 1, 3, 4, and 6 indicate that the default value is likely
> "immutable".
> Test cases 2 and 5 indicate that the "none" value behaves as described
> after correcting the statement that fields will be reloaded.
> The test cases indicate that the behavior for "immutable" setting does
> not work as expected, since the behavior depends on whether the field is
> eagerly or lazily loaded (and perhaps on fetch group configurations as
> well.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-514) Problems with the
openjpa.RestoreState property
Posted by "David Ezzio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Ezzio updated OPENJPA-514:
--------------------------------
Let me try to explain more clearly.
Section 3.3.2 of the JPA 1.0 spec is very clear: "For both transaction-scoped and extended persistence contexts, transaction rollback causes all pre-existing
managed instances and removed instances to become detached."
Thus on rollback, under any circumstances, the result is a clearing of the persistence context. This is verified by checking the AutoDetachType properties of a simply opened EntityManager in a JSE test case. ROLLBACK and CLOSE are the two settings. In extended contexts with OpenJPA, autodetachment occurs upon rollback and close, but not upon commit or non-transactional-read. In a transactionally-scoped context, autodetachment occurs in all four events.
So the notion that there will be any entities around to reload after rollback is flat out wrong. The OpenJPA documentation at http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_pc_scos_restore is therefore incorrect.
Also, as the test cases show when you play with the RestoreState property, the default value appears to be "immutable" rather than "none". Consequently, either the implementation or the documentation is incorrect on this point. I don't know which.
Finally, either the documentation or the implementation is incorrect regarding the implication in the OpenJPA documentation that the RestoreState property controls the behavior. As the test cases show, the behavior depends at least in part on whether the fields are eagerly or lazily loaded, and whether an eagerly loaded field is dirtied before the lazily loaded field is dirtied. Since I believe that regimentation is a sure path to simplicity (because it reduces the learning curve), I think the implementation may be in error here as well as the documentation.
In terms of what the behavior should be, my bias is for useful behavior that can be explained in the fewest words. So, I think the property should always control the behavior (no possibility of other factors affecting the outcome), and I would think that three states would be acceptable: none (as the default, with perhaps the name changed to "unloaded") resulting in all fields (except ID fields) being unloaded, a new state "before-image" resulting in a roll back to the state that existed before the object was first dirtied, and a new state "no-action" resulting in no action by OpenJPA on the loaded or unloaded state of the fields. None of these behaviors implies a "reloading" during rollback. Reloading is probably useless.
> Problems with the openjpa.RestoreState property
> -----------------------------------------------
>
> Key: OPENJPA-514
> URL: https://issues.apache.org/jira/browse/OPENJPA-514
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.1.0
> Environment: Windows, at OpenJPA revision 619978
> Reporter: David Ezzio
> Attachments: TestCasesOpenJPA-514.zip
>
>
> Section 3.3.2 of the JPA spec is clear that upon rollback, all managed
> instances become detached, and in their detached state they may not be
> consistent or reusable as normally detached instances would be.
> OpenJPA has a property "openjpa.RestoreState" for which it claims a much
> stronger behavior. In section 5.6.1, the OpenJPA manual says:
> "While the JPA specification says that you should not use rolled
> back objects, such objects are perfectly valid in OpenJPA. You can
> control whether the objects' managed state is rolled back to its
> pre-transaction values with the openjpa.RestoreState configuration
> property. none does not roll back state (the object becomes hollow,
> and will re-load its state the next time it is accessed), immutable
> restores immutable values (primitives, primitive wrappers, strings)
> and clears mutable values so that they are reloaded on next access,
> and all restores all managed values to their pre-transaction state."
>
> In section 2.5.53, the OpenJPA manual identifies three values for the
> the openjpa.RestoreState value. It identifies "none" as the default
> value.
> In fact, two central statements in the above cited passages from the
> OpenJPA manual are not true. In addition, the behavior in restoring
> fields is controlled at least in part by other factors.
> To begin with, a detached object will not reload any state. In the
> second instance, the default value appears to be "immutable" instead of
> "none".
> Two test cases were run with the entity class Dohickey. Dohickey has two
> string fields, lazy and eager, as well as an integer identity field.
> Both test cases use a new entity manager. In the first test case, the
> lazy field is dirtied in a newly found a Dohickey. In the second test
> case, the lazy field is dirtied after dirtying the eager field in a
> newly found Dohickey. In both test cases, the transaction is rolled
> back. The detached Dohickey is then tested for detachment, and for
> whether the values of the eager and lazy fields match the values in the
> database.
> Number Test case RestoreState Restored Eager Restored Lazy
> ------+------------+---------------+--------------+--------------
> 1 Lazy only undefined db value dirty value
> 2 Lazy only none null null
> 3 Lazy only immutable db value dirty value
> 4 Eager first undefined db value null
> 5 Eager first none null null
> 6 Eager first immutable db value null
> Test cases 1, 3, 4, and 6 indicate that the default value is likely
> "immutable".
> Test cases 2 and 5 indicate that the "none" value behaves as described
> after correcting the statement that fields will be reloaded.
> The test cases indicate that the behavior for "immutable" setting does
> not work as expected, since the behavior depends on whether the field is
> eagerly or lazily loaded (and perhaps on fetch group configurations as
> well.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.