>> pp. 489 ff.: Conversation = Session holding multiple >> Transations, objects stay attached (but that doesn't >> work as soon as the Session dies due to any exception) >> >> Well, I *thought* I could use the model described on >> pp. 489 ff. Except Sessions are too fragile - and no >> mention of that in the entire book. > > I guess the reason behind this is that when a database > exception is thrown, it is too difficult to figure out > which parts of the session objects graphs are invalid > or should be restored.
That has been my thinking, too. But: 1) There are ways to find out whether a JDBC session and the transaction are still alive. It's hard because many JDBC drivers have bugs, but in the worst case, you can simply change something inconsequential that will be undone on rollback, and query that. 2) You still can't put the Hibernate session back into the state it was before the failure. You have no way to inspect the first-level cache to find out what objects were changed and would need to be set up again! You have to do all that at the application level. > In the hibernate philosophy, you should just discard > the session, log the exception somewhere and perhaps > show some message or throw a 500 error. That's my thinking, too - and that's why I conclude that Hibernate simply isn't built for long-running conversations, despite Bauer/King claiming the opposite. (For me, the nasty thing was that I had my application designed around long-running conversations. I discovered this fragility after a year of happy coding. Hibernate rightfully earned my hate for that!) > As for detaching, reattaching objects, I'd just say > no thanks! Detached objects are to be considered stuffed > with TNT, I'd rather use IDs and DTOs which I know are > safe and serializable. Hm... well, sort of. You want all kinds of caches, e.g. for filling in drop-down lists. They might go stale, but you don't want to load these objects from the database every time unless you have to. You might say that drop-down lists aren't that important, and I'd say you're right :-) ... but they are just a model for the use case I'm actually have: a mostly-constant rules table that currently has a five-digit number of rows, that we really don't want reloaded on every request. Of course, keeping track of changes in that table and updating the cache is one of the areas where ad-hockery abounds. > if you keep your data loading stuff close enough to the > code using it and don't pass half filled data objects > everywhere, you should be fine. I think this would work for 99% of application coding happening. I do not think that this scales to arbitrary code complexity though, in particular if you have to observe space constraints - then you MUST work with incompletely-loaded object graphs. I don't see this become a use case in business applications :-) ... but for the AI logic in game server programming, I do see this happening, on a regular basis actually. (Databases and game servers aren't a match made in heaven anyway... you need Eventual Consistency, Integrity, and Durability, but no Immediate Consistency and Atomicity is just a nice-to-have. Probably a case for NoSQL. But then most game servers still run on classic databases, if only to allow ad-hoc SQL queries, and they just take the performance hit.) -- 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.
