Re: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl

Tue, 30 Oct 2007 13:00:40 -0800 

Hi Evan,

On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote:


Kevin,

  JPA 1.0 section 3.2.3 Synchronization to the Database

  ...

  An update to the state of an entity includes both the assignment
  of a new value to a persistent property or field of the entity
  as well as the modification of a mutable value of a persistent
  property or field.

If you have to call the setter method again in order for the
change to be detected, surely this would not be spec-compliant.

Should we report this as a bug?
Yes, please report it as a bug, and include a trivial test case. We can then resolve it on the jira discussion. 

I wonder if there is a TCK test for this?
One way to handle this kind of thing is to define an OpenJPA flag like "AutoDetectArrayChanges" which has a negative performance impact because it requires OpenJPA to compare the before-image and after- image of all xxx[ ] field values at flush or commit time. If the flag is false, then the only array types that are detected are those in which the field is replaced (even by itself). The default could be spec-compliant (true) or non-spec-compliant. The TCK might have to run with the flag set to slow, depending on whether there even is a TCK test. 

Craig



-----Original Message-----
From: Kevin Sutter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 31 October 2007 2:38 a.m.
To: [email protected]
Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
contained in a detached Entity still have a "live" StateManagerImpl

Evan,

On 10/28/07, Evan Ireland <[EMAIL PROTECTED]> wrote:


Since you appear to be familiar with the proxying stuff, I

wonder if

you can say, for persistent attributes of type "byte[]"

which cannot

be proxied, but are mutable, how does OpenJPA handle that case?



As one big blob of data...  :-)   If you modify the
individual byte array
contents, then you will have to re-set the array into your
persistence field in order for the change to be detected.

OpenJPA also provides the ability to define a customized type
plugin which might allow you to define and detect a byte[]
modification, but I'm not totally familiar with this aspect
to know if it would help your situation or not.

Kevin





-----Original Message-----

From: Kevin Sutter (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Sunday, 28 October 2007 9:22 a.m.
To: [email protected]
Subject: [jira] Resolved: (OPENJPA-422) Calendar objects

contained

in a detached Entity still have a "live" StateManagerImpl


     [
https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
assian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Sutter resolved OPENJPA-422.
----------------------------------

    Resolution: Fixed

Resolved for 1.0.1 and 1.1.0 via svn revision 589207.


Calendar objects contained in a detached Entity still

have a "live"

StateManagerImpl




--------------------------------------------------------------------

--

--------------

                Key: OPENJPA-422
                URL:

https://issues.apache.org/jira/browse/OPENJPA-422

            Project: OpenJPA
         Issue Type: Bug
         Components: kernel
   Affects Versions: 1.0.0
           Reporter: Kevin Sutter
           Assignee: Kevin Sutter
            Fix For: 1.0.1, 1.1.0


When Entities are detached, normally the StateManagerImpl

instance associated with this Entity is replaced with a
DetachedStateManager.  Not only with the Entity itself, but also
with the proxied attributes (Date, Calendar, Collection, and Map
types).  But, somehow the Calendar object type was

forgotten in the

code for this processing.  So, the Calendar proxy type

was left with

a "live" StateManagerImpl instance.
If the owning Broker (EntityManager) for this Entity was closed,
then the use of this "live" StateManagerImpl would end up with an
IllegalStateException.  And, even if the owning Broker
(EntityManager) was still open, this "live"
StateManagerImpl should not have been tracking the state

since the

enclosing Entity was detached.

A simple one-line update to

DetachManager$DetachFieldManager.reproxy() method will

now process

the Calendar proxies as well as the other proxies it was already
doing.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.











Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to