Hello, 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.
Exactly what I do, hibernate entities are not to be used as DTOs. I am using both hibernate and jooq, in the same project but different sections. I use jooq mostly for reporting and displaying tabular data, I use hibernate mostly for my business logic because operations on a single table are quite rare. I know that many people hate hibernate because they think it's too much magic, it's partly true but I'd say it's also probably the most misused framework on the planet. There are countless of posts everywhere showing that people rely too much on lazy loading and long lived sessions, they would like to deal with their database just like if it was fully loaded into memory, run out of resources and experience slowness because they want to stay in an object oriented world and totally ignore SQL, stored procedures. Imho hibernate itself is rarely the unique cause of disaster, you can carefully check display and check the SQL output or every operation, and if it's close enough to what you would write yourself, it can't be bad. Now what really prevents me from using jooq everywhere? I stopped using mybatis the exact same week I learnt about jooq, but I could not do the same with hibernate for the following reason: Jooq is excellent for issuing complex SQL, it has everything you could dream of, strong typing, a very readable DSL but it doesn't help much when you need to efficiently load and manipulate graphs. Suppose I want to load a collection of objects with 2 or more one-to-many relationships, I have the following options 1) Fetch a collection of records from the main table, and use fetchX methods to navigate which is ok for 1 or 2 records but totally inefficient when used in a loop 2) Issue one query + 2 correlated queries queries and do the mapping in memory, which is error prone, requires a lot of code and has a huge negative impact on my productivity. Given enough free time, I could think of a way to implement caching for the fetchXXX methods, but past the 2 or 3 basic use cases, I'd be reinventing hibernate. It doesn't mean there isn't any solution in between (I mean between JPA and Jooq), an excellent .Net commercial ORM called LLblgen which is also based on generated code offered a great, predictable graph loading AP without relying on obscure caching mechanisms. Le mercredi 31 juillet 2013 17:51:56 UTC+2, Lukas Eder a écrit : > > > > > 2013/7/31 Durchholz, Joachim <[email protected]<javascript:> > > > >> >> (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... >> > > Aw. I try to be open minded on that subject, so I'm not going to comment > :-) > > >> > 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. >> > > You probably mean this: > http://i.imgur.com/l3aFizL.jpg > -- 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.
