>> (still not using Jooq yet, unfortunately): > > When will you finally use it! :-)
Heh. When I'm at a new job I fear... no resources for that shift :-( But my current employer does have a job opening announced, maybe something will happen. > Hmm, I'm surprised that you have to reload all data > when you get an exception. Well, you'll need to do that anyway. You're starting a new transaction, and somebody may have modified your records behind your back. The real issue is that you can't reinsert the existing Pojos into the new Session; the new Session insists on its own, new set of Pojos. Not a problem if you do short transactions^Wconversations exlusively. I.e. never keep any Pojo around for longer than immediately necessary, keep only primary keys. It's the standard model of operation for web services, so that isn't a problem for the standard application domain of Hibernate. For long-running applications, you want to keep the Pojos around. You keep them in caches. But with Hibernate, you can't, because the Session may die and the Pojo becomes unusable. You could keep track of what caches those Pojos are in and replace them with new ones as a new Session comes up, but (a) this is wasteful because you reload even if the Pojo happens to be never written back but you don't know this, (b) all hopes of modularity go out of the window. The best you can do is to always work with detached objects, and at commit time, always reload and merge() them. The trouble is that you lose the single-UPDATE optimization, you know have two round trips to the database. For every friggin' object. And the Hibernate book devotes an entire chapter to long conversations... > It's a common pattern to try to insert something, check for > a constraint violation, and then insert something else or > update something. [...] So you're saying, with Hibernate you > cannot make use of exceptions from constraint violations, or > raised from stored procedures? The official word is that the Session should not be relied on. If you look carefully, you can't even roll it back or close it, the Hibernate docs say it's invalid. There is no distinction between "harmless" and "destroying" exceptions. In practice, people ignore that and simply continue with a Session that had an exception. The trouble is that this will probably work, most of the time, except when it doesn't. Regards, Jo -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
