Thanks, Peter, for your answers... More comments below...
On Tue, May 12, 2009 at 5:08 PM, Peter Henderson <
peter.hender...@starjar.com> wrote:
> Hi Kevin,
>
> Thanks for your comments.
>
> 1) I am using transactions simply because this test was pared down for more
> complex code.
Good, makes sense. Just wanted to clarify that.
>
> 2) Because I'm not the smartest tool in the box. Probably legacy from using
> another JPA implementation which would only give meaningful errors at flush.
:-) Fair enough. It shouldn't hurt anything, but I would remove the flush.
>
> 3) em.clear()
> This is where things get interesting. Calling em.clear() with/without
> em.detach() before closing the em breaks Hessian serialization.
Do you close the EM before doing the serialization? If a close is always
performed, then the detach processing should already be done for you and
none of these options should need to be applied.
Is there anything unique to this Hessian serialization? Have you tried just
Java serialization to a byte array? Just trying to narrow down the
problem. As you have probably surmised by now, this detachment processing
should be working. We have several tests within our JUnit bucket that tests
detachment and serialization. Of course, there still may be a lurking bug
of some type...
> 4) I've tried with and without
> openjpa.AutoDetach="commit, close"
> and
> openjpa.DetachState="loaded(DetachedStateField=false,
> DetachedStateManager=false)"
> neither seem to make any noticeable difference.
Cool. The DetachState was another idea, but I figured why go there when the
basic detachment didn't seem to work for you.
>
> One thing I have noticed, the date field class of my entity changes when I
> call em.detach() but not when I call em.clear(). This maybe well be normal
> behaviour.
>
> e.g.
>
> Detach.
>
>
> pre em.detech() res.getCreatedOn().class
> class org.apache.openjpa.util.java$util$Date$proxy
> T = em.detach(T);
> post oem.detach() res.getCreatedOn().class
> class java.util.Date
>
>
> Clear
>
> pre oem.clear() res.getCreatedOn().class
> class org.apache.openjpa.util.java$util$Date$proxy
> em.clear();
> post oem.clear() res.getCreatedOn().class
> class org.apache.openjpa.util.java$util$Date$proxy
>
We wrapper the Date and Timestamp classes (and a few others) in Proxy
classes so that we can monitor changes to these type of attributes. The
normal processing should be along the lines of the detach() processing that
you see above. This way, the detached entity would not be dependent on any
of the OpenJPA code. The clear processing doesn't look right to me. It
looks like we our detached entity in this case would still be dependent on
on the OpenJPA code. Unless someone can correct me, this looks like a bug.
But, it still doesn't answer your original problem...
Thanks,
Kevin
> Kevin Sutter wrote:
>
>> Hi Peter,
>> Maybe your example was simplified just to show the error, but I have a
>> couple of questions on the application logic that was posted...
>>
>> o Why are you performing a transaction begin/commit when you are only
>> reading data? If your access is read only with no intent on updates, then
>> a
>> transaction is overkill.
>>
>> o Why are you calling flush before the commit? A commit invocation has
>> an
>> implicit flush action, so there is no reason to call flush explicity (in
>> this case anyway).
>>
>> o Is an em.clear() doable for your environment? This would detach all
>> entities in the EM's persistence context upon invocation.
>>
>> o The openjpa.AutoDetach property probably pre-dates the JPA spec. Have
>> you tried running without this property?
>>
>> Kevin
>>
>> On Tue, May 12, 2009 at 8:58 AM, Peter Henderson <
>> peter.hender...@starjar.com> wrote:
>>
>> Thanks for replying.
>>>
>>>
>>> The stack trace is within Hessian (server side)
>>>
>>>
>>> StandardWrapperValve[AccountsService]: PWC1406: Servlet.service() for
>>> servlet AccountsService threw exception
>>> java.lang.StackOverflowError
>>> at
>>> com.caucho.hessian.util.IdentityIntMap.get(IdentityIntMap.java:114)
>>> at
>>> com.caucho.hessian.io.Hessian2Output.addRef(Hessian2Output.java:1314)
>>> at
>>> com.caucho.hessian.io.JavaSerializer.writeObject(JavaSerializer.java:141)
>>> at
>>> com.caucho.hessian.io.Hessian2Output.writeObject(Hessian2Output.java:490)
>>> at
>>> com.caucho.hessian.io.JavaSerializer.writeObject(JavaSerializer.java:153)
>>> at
>>> com.caucho.hessian.io.Hessian2Output.writeObject(Hessian2Output.java:490)
>>> at
>>> com.caucho.hessian.io.JavaSerializer.writeObject(JavaSerializer.java:153)
>>> at
>>> com.caucho.hessian.io.Hessian2Output.writeObject(Hessian2Output.java:490)
>>> .
>>> .
>>> .
>>>
>>>
>>> Which seems to suggest it is recursively walking the object graph never
>>> reaching the end. (and the object graph is very simple [1])
>>>
>>> This could be related to dates, although I am not sure atm.
>>>
>>>
>>>
>>>
>>> PS
>>> I am using OpenJPA 1.2.1 on Java 1.6.0_13 on Ubuntu linux 64bit.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1] My entity class
>>> @Entity
>>> @Table(name = "accounts")
>>> @NamedQueries({
>>> @NamedQuery(name = "Account.findByParentAccountId",
>>> query = "SELECT a FROM Account a WHERE a.parentAccountId =
>>> :accountId"),
>>> @NamedQuery(name = "Account.findRootAccountsByCategoryId",
>>> query = "SELECT a FROM Account a WHERE a.accountCategoryId =
>>> :accountCategoryId AND a.parentAccountId is null AND a.deletedOn is
>>> null")
>>>
>>> })
>>> @EntityListeners(AccountHelper.class)
>>> public class Account
>>> implements Serializable {
>>>
>>> @GeneratedValue(strategy = GenerationType.IDENTITY)
>>> @Id
>>> @Column(name = "account_id", nullable = false)
>>> private Integer accountId;
>>>
>>> @Column(name = "account_type", nullable = false)
>>> private int accountType;
>>>
>>> @Column(name = "name", nullable = false)
>>> private String name;
>>>
>>> @Column(name = "full_name", nullable = false)
>>> private String fullName;
>>>
>>> @Column(name = "description")
>>> private String description;
>>>
>>> @Column(name = "manager", nullable = false)
>>> private String manager;
>>>
>>> @Column(name = "tree_depth", nullable = false)
>>> private int treeDepth;
>>>
>>> @Column(name = "balance", nullable = false, precision = 20, scale = 6)
>>> private BigDecimal balance;
>>>
>>> @Column(name = "created_on")
>>> @Temporal(TemporalType.TIMESTAMP)
>>> private Date createdOn;
>>>
>>> @Column(name = "created_by")
>>> private String createdBy;
>>>
>>> @Column(name = "deleted_on")
>>> @Temporal(TemporalType.TIMESTAMP)
>>> private Date deletedOn;
>>>
>>> @Column(name = "deleted_by")
>>> private String deletedBy;
>>>
>>> @Column(name = "parent_account_id")
>>> private Integer parentAccountId;
>>>
>>> @Column(name = "account_category_id")
>>> private Integer accountCategoryId;
>>>
>>> @Column(name = "nominal_code")
>>> private String nominalCode;
>>>
>>> ** snip getters/setters hashCode equals toString **
>>> }
>>>
>>>
>>>
>>> Rick Curtis wrote:
>>>
>>> Peter -
>>>>
>>>> What kind of problems are you having? An exception or stack trace would
>>>> be
>>>> very helpful.
>>>>
>>>> -Rick
>>>>
>>>> Peter Henderson wrote:
>>>>
>>>> ...
>>>>>
>>>>> If I don't manually call em.detach() I get lots of problems when
>>>>> hessian
>>>>> tries to serialize the object for wire transfer.
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> --
>>> Peter Henderson
>>> Director Starjar Limited.
>>>
>>> Mobile: +44 (0) 778 233 8645
>>> Email: peter.hender...@starjar.com
>>> Web: www.starjar.com
>>>
>>>
>>>
>>
>
> --
> Peter Henderson
> Director Starjar Limited.
>
> Mobile: +44 (0) 778 233 8645
> Email: peter.hender...@starjar.com
> Web: www.starjar.com
>
>
