Testgram:
public class PrimaryKeyTest extends StandaloneIntegrationScript {
/**
* @param args
*/
public static void main(String[] args) {
ManufacturerService service = (ManufacturerService)
applicationContext.getBean("manufacturerService");
Manufacturer manufacturer = new Manufacturer();
try {
service.save(manufacturer);
} catch (Exception e) {
System.out.println(e.getMessage());
}
System.out.println("Primary Key: " + manufacturer.getId());
}
}
Output:
not-null property references a null or transient value:
com.dynedge.guardian.model.Manufacturer.name; nested exception is
org.hibernate.PropertyValueException: not-null property references a
null or transient value: com.dynedge.[...].model.Manufacturer.name
Primary Key: 19
Note: This is almost exactly what my Tapestry listener is doing, except
the (Spring) service is being injected via @InjectObject, whereas my
StandaloneIntegrationScript class that this one inherits from creates
the Spring applicationContext manually.
This might be specific to using sequences, or even just Postgres
sequences: I'm using Postgres sequences in the backend, and Hibernate
is first querying out/incrementing the sequence, then setting the result
to the object's primary key, and /then/ trying to perform the INSERT --
which is throwing the expected Exception above.
I asked about nearly the same issue on the Hibernate forums a few weeks
ago ( http://forum.hibernate.org/viewtopic.php?t=958168&highlight= ),
and was told: "The state of the entities that you tried to save are also
unstable." If that poster is right, then this isn't technically a bug.
i.e. if the contract is that Hibernate can "screw up" the objects, then
I can't even assume that it's just the primary key and Postgres that
could be left unstable -- Hibernate could potentially be doing anything
to my object.
Unfortunately, the Hibernate docs themselves are less clear; the only
thing I can find is section 11.2.3 (Exception Handling): "Certain
methods of Session will not leave the session in a consistent state. No
exception thrown by Hibernate can be treated as recoverable." Dunno if
that's intended to include the entities passed in.
Jim Steinberger
Dynamic Edge, Inc.
734.975.0460 x 101
[EMAIL PROTECTED]
-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 8:18 PM
To: 'Tapestry users'
Subject: RE: Insert/Update pages and Hibernate
Jim,
Oooh! That's nasty and I was unaware of the issue (assigning a primary
key,
but not really committing the transaction). Do you have documentation
of
the phenomenon or maybe some unit test code that would exhibit that
behavior
(I'm not calling you a liar; I just want to see it in action and maybe
try
to figure out how to code around it)?
Thanks,
James
-----Original Message-----
From: Jim Steinberger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 8:16 PM
To: Tapestry users
Subject: RE: Insert/Update pages and Hibernate
Paul,
Thanks much -- I take your points well; there are certainly some things
I'm considering changing. If you could, though, I'm having trouble
relating them to this specific case; here's a basic listener:
public IPage saveManufacturer() {
try {
getManufacturerService().createManufacturer(getManufacturer());
} catch (Exception e) {
setError("Could not create Manufacturer: " + e.getMessage());
return this;
}
}
You suggested throwing away the bad object (getManufacturer()), but if I
do that, I'm throwing away all the data the user entered, forcing them
to retype everything -- and I couldn't query that from persistence
because it was never persisted in the first place (the primary key on my
object is invalid because the INSERT never happened).
I had previously assumed that Hibernate not change my objects if the
database transaction didn't complete. e.g. if the INSERT fails, I
assumed Hibernate wouldn't set my primary key. I only found out
recently that this was a bad assumption; if something goes wrong, the
objects passed in can be mutated.
_Effective Java_ would tell me to, then, clone my objects before
passing them to an API that could potentially mutate them, since I need
to keep the original data around (the user input). But I've never seen
anyone doing this, so I'm asking about this situation here because
either I'm missing something or a lot of other people are.
Jim
-----Original Message-----
From: Paul Cantrell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 7:12 PM
To: Tapestry users
Subject: Re: Insert/Update pages and Hibernate
There are several practices you can use to avoid painting yourself
into this corner:
(1) Probably the best and simplest: Use a straightforward transaction-
per-request model, and don't ever hold on to persistent objects
between requests.* Instead, hold on to the IDs of your persistent
objects. Think of the persistent objects as a fleeting view of the
app's persistent state, a view that will vanish at the end of the
request. Keep enough user input and working values in your page to be
able to get all the way from a cleanly fetched object to a
committable one, in one go -- instead of poking and prodding the
persistent object to its ultimate committable state across several
requests.
Having a custom Tapestry SqueezeAdaptor for your persistent objects
makes this quite simple: you page properties can all look like the
full persistent objects, but Tapestry will only store the ID between
requests.
It sounds like your problems are cause by having a broken persistent
object dangling from your page. Solution? Don't attach it to the
page! Throw it away when the request is done. Let your listeners
fetch it again clean next time.
(2) On the heels of (1), always roll back on error. You can do this
in your transaction interceptor or servlet filter; it's also possible
to do it in validator / listener methods. A mix of both may be
appropriate.
Sounds like you may already be doing this -- but when combined with
(1), you know that your DB and your objects are clean after a
failure, and only the page itself remains messy.
(3) Make your domain objects "fail fast:" enforce constraints up
front, and when possible, don't let objects get into an invalid state
to begin with. In your case, that means not storing the PK back to
the page until the create has succeeded.
(4) To make (3) really work, ensure your domain objects observe
strict failure atomicity. See _Effective Java_ for an explanation.
(Order a copy if you don't own it! It's a marvelous book.)
I hope that is helpful.
Cheers,
Paul
* In some situations, holding persistent objects between requests is
the right approach. However, I believe these situations are rare. The
pitfalls of this approach are large, and the performance benefits are
often overstated (especially if you use caching).
On May 2, 2006, at 5:42 PM, Jim Steinberger wrote:
> In Tapestry, we use model objects as the data-buffer. If we're
> editing an entity, and something goes wrong, we can set an
> errorMessage
> property, "return this;", and expect the user to see the form still
> filled-out with what they'd just typed with an explanation of what
> went
> wrong.
>
> If you're using Hibernate, however, I don't think this use-case is
> guaranteed; mainly because I'm currently dealing with cases where it
> isn't.
>
> What I mean by that: If something goes wrong in a Hibernate
> session,
> your entities are not guaranteed to be left in a stable state. i.e.
> they're not guaranteed to match their counterparts in the persistence
> layer.
>
> In my case, I'm trying to insert an object with some not-null
> properties left as null. Hibernate sets the primary key of my object
> (when it queries my Postgres sequence), but then fails on the actual
> entity-insert. An exception is thrown, but the primary key is left on
> my object. Since my Tapestry page is designed to handle both creating
> and updating this entity -- and since it does this by testing
> whether or
> not an object's primary key exists -- the user is told there was a
> problem, but as far as Tapestry is concerned, the user is now editing
> the entity, not creating it.
> I can hack it by explicitly setting the primary key to be null
> where I
> catch the Exception, but who knows what else Hibernate might be
> mutating
> without going through the source code.
>
> Am I crazy, or does this Hibernate practice mean that, everywhere we
> expect to be able to use an object even if something goes wrong in
> Hibernate, we have to clone our entity first or open ourselves up to
> potential problems? Are people doing this?
>
>
> Jim
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
