openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Ezzio (JIRA)" <j...@apache.org>
Subject [jira] Created: (OPENJPA-514) Problems with the openjpa.RestoreState property
Date Mon, 11 Feb 2008 17:26:08 GMT
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.


Mime
View raw message