Things I wish I'd Known Earlier

But learned the hard way!

Detached objects and JSF

Written by Tim on July 23, 2008

JSF and JPA have proven to be more problematic than expected. The upside of the JSF framework is that the datamodel objects can be presented more or less right up to the page view layer without recourse to Data Transer Objects (DTOs). The downside, is that what’s presented isn’t always clear, leading to the dreaded OptimisticLockingException.

Officially, you get an Optimistic Locking Exception when your in-memory model is out of sync with the database (the database is more up-to-date than the model). In actuality, all that really needs to happen is for the ORM manager to think the model is out of sync with the database.

This perception seems to be distressingly easy cause. I’d blame it on a bug in OpenJPA, but I had similar issues with the detach/attach model of JDO. I’ve not seem any good writeups on how to prevent the problem, but I’ve come up with a means of handling it (right or wrong).

In Struts, the issue was more obvious. It may be the same mechanism in JSF, just more obscure.

Here’s what happens:

1. You fetch in a record, display it, get the user’s input back.

2. You merge the update with the database. OB so far.

By default, JSF will redisplay the same form. If you then do more changes and attempt to merge them, you get an OptimisticLockingException.

In theory, this shouldn’t be happening, but in the current and development releases of OpenJPA (up to 1.2.0), I can do only one merge.

As it turns out, the simple solution is to do the update, then fetch a brand-new copy of the object if further edits are required/anticipated. That makes it almost a return to the old-time concept of EJB where a handle could be used to re-activate a copy of the EJB. Only instead of a handle, use the object’s primary key. This should be low-overhead assuming the object’s still in cache, but it is irritating.

As to what’s actually causing the problem, it seems that the “dirty” flags for the object don’t get cleared when the merge is done and the EntityManager merge() method returns the object. So on the next merge, the database is updated, but the original pre-merge criteria were applied.

Posted In Java Persistence Architecture (JPA) and related ORM
Tagged attach | detach | JPA | JSF | ORM

Post navigation

PreviousOpenJPA, Tomcat6, Spring and Hibernate
NextORM and Imprecise Data Types

Categories

  • Android
  • Bad Practices
  • Better Software Design
  • Enterprise Java
  • Hardware
  • Internet of Things
  • Java Persistence Architecture (JPA) and related ORM
  • Libre Office
  • MillRight CNC
  • Random maniacal ravings
  • Stupid Linux Tricks
  • The Cloud
  • Uncategorized
May 2022
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« Jun    

Categories

  • Android
  • Bad Practices
  • Better Software Design
  • Enterprise Java
  • Hardware
  • Internet of Things
  • Java Persistence Architecture (JPA) and related ORM
  • Libre Office
  • MillRight CNC
  • Random maniacal ravings
  • Stupid Linux Tricks
  • The Cloud
  • Uncategorized

Tags

Android annoyances jpa hibernate Apache Arduino attach ATTiny85 centos centos 7 configuration date/time design detach DigiSpark documents Enterprise Java Facelets floating-point fonts graphviz hibernate howto IDE Imprecise data types JBoss JPA JSF linux Maven oowriter openjpa ORM recipe RichFaces scalable graphics security spring testing Tomahawk Tomcat tomcat5 tomcat6 Tomcat Instrumentation vector graphics weaver Xen

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
Copyright © 2022. Things I wish I'd Known Earlier
Powered By WordPress and Auspicious