You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Peter Henderson <pe...@starjar.com> on 2009/05/12 12:42:11 UTC
AutoDetach
I am new to OpenJPA and run into a little confusion over
auto detaching.
My setup.
Hessian servlet [1] which does some JPA and returns an
object. This acts as the server for a remote Swing client.
In my persistence.xml [2] I have
<property name="openjpa.AutoDetach" value="close, commit"/>
Which I understand should detach objects when a TX commits
or the entity manager closes.
If I don't manually call em.detach() I get lots of problems
when hessian tries to serialize the object for wire transfer.
Have I miss configured my persistence.xml or is there some
other (simpler) way of detaching objects without having to
manually call em.detach()?
Peter.
[1] Sample Servlet function.
public Account loadAccount(Integer accountId) {
EntityManager em = getEntityManagerBeginTx();
Account res = null;
try {
res = em.find(Account.class, accountId);
res = detach(em, res); // this makes it work
} finally {
returnEntityManager(em);
}
return res;
}
protected void returnEntityManager(EntityManager em) {
if (em.getTransaction().isActive()) {
em.flush();
em.getTransaction().commit();
}
em.close();
}
protected <T> T detach(EntityManager em, T pc) {
return ((OpenJPAEntityManager)em).detach(pc);
}
[2] persistence.xml (edited to remove class listing)
<?xml version="1.0"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="StarjarEnterpriseOpenjpaPU">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>jdbc/StarjarEnterprise5DS</jta-data-source>
<class>com.starjar.starjarenterprise5.domain.Account</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="openjpa.Log" value="DefaultLevel=INFO,
Runtime=ERROR, Tool=ERROR, SQL=ERROR, DataCache=ERROR"/>
<property name="openjpa.AutoDetach" value="close,
commit"/>
</properties>
</persistence-unit>
</persistence>
--
Peter Henderson
Director Starjar Limited.
Mobile: +44 (0) 778 233 8645
Email: peter.henderson@starjar.com
Web: www.starjar.com
Re: [SOLVED] Re: AutoDetach
Posted by Kevin Sutter <kw...@gmail.com>.
Excellent news, Peter! Thanks for the update.
Kevin
On Wed, May 13, 2009 at 3:23 AM, Peter Henderson <
peter.henderson@starjar.com> wrote:
> Kevin,
>
> Many thanks for you help!
>
> Your suggestion to try plain Java serialization got me thinking. I did a
> test using ObjectOutputStream before & after detaching and it worked fine,
> so I thought perhaps the problem really is with Hessian. (I know, how could
> I have doubted you guys)
>
>
> I've since replace Hessian 3.1.6 with version 3.2.1 and removed all calls
> to em.detach() em.clear().
>
> Now everything works as expected! All my test cases succeed.
>
>
> Hopefully this message will help anyone else who runs into this problem.
>
>
> Cheers
>
> Peter.
>
>
> --
> Peter Henderson
> Director Starjar Limited.
>
> Mobile: +44 (0) 778 233 8645
> Email: peter.henderson@starjar.com
> Web: www.starjar.com
>
>
[SOLVED] Re: AutoDetach
Posted by Peter Henderson <pe...@starjar.com>.
Kevin,
Many thanks for you help!
Your suggestion to try plain Java serialization got me
thinking. I did a test using ObjectOutputStream before &
after detaching and it worked fine, so I thought perhaps the
problem really is with Hessian. (I know, how could I have
doubted you guys)
I've since replace Hessian 3.1.6 with version 3.2.1 and
removed all calls to em.detach() em.clear().
Now everything works as expected! All my test cases succeed.
Hopefully this message will help anyone else who runs into
this problem.
Cheers
Peter.
--
Peter Henderson
Director Starjar Limited.
Mobile: +44 (0) 778 233 8645
Email: peter.henderson@starjar.com
Web: www.starjar.com
Re: AutoDetach
Posted by Kevin Sutter <kw...@gmail.com>.
Thanks, Peter, for your answers... More comments below...
On Tue, May 12, 2009 at 5:08 PM, Peter Henderson <
peter.henderson@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.henderson@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.henderson@starjar.com
>>> Web: www.starjar.com
>>>
>>>
>>>
>>
>
> --
> Peter Henderson
> Director Starjar Limited.
>
> Mobile: +44 (0) 778 233 8645
> Email: peter.henderson@starjar.com
> Web: www.starjar.com
>
>
Re: AutoDetach
Posted by Peter Henderson <pe...@starjar.com>.
Hi Kevin,
Thanks for your comments.
1) I am using transactions simply because this test was
pared down for more complex code.
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.
3) em.clear()
This is where things get interesting. Calling em.clear()
with/without em.detach() before closing the em breaks
Hessian serialization.
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.
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
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.henderson@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.henderson@starjar.com
>> Web: www.starjar.com
>>
>>
>
--
Peter Henderson
Director Starjar Limited.
Mobile: +44 (0) 778 233 8645
Email: peter.henderson@starjar.com
Web: www.starjar.com
Re: AutoDetach
Posted by Kevin Sutter <kw...@gmail.com>.
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.henderson@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.henderson@starjar.com
> Web: www.starjar.com
>
>
Re: AutoDetach
Posted by Peter Henderson <pe...@starjar.com>.
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.henderson@starjar.com
Web: www.starjar.com
Re: AutoDetach
Posted by Rick Curtis <cu...@gmail.com>.
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.
>
> ...
>
--
View this message in context: http://n2.nabble.com/AutoDetach-tp2868435p2869165.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.