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.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
