-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/13/10 15:59 , Kevin Wright wrote: > The idea of silently having an object always persisted is > certainly an appealing one. > > Shame it doesn't work so well in practice, in order to avoid > issues of persisting an object (or multiple related objects) in an > inconsistent state we need some form of transactions, or > "checkpoints" where a session is manually flushed/saved. > > That's usually where the problems begin, especially with the > involvement of threads...
Of course you're right, this yet another point. But you have problems even when you don't have so much threading issues (e.g. a single user, simple desktop application - or even better, a single user smartphone application). Jitesh, the problem with Hibernate is in the practice, not in the theory (and I'm not even thinking of XML, since in the past three years for me Hibernate is just an implementation of JPA -> annotations). I've seen more than one customer having a large application based on Hibernate and then experiencing lots of issues related to integration and performance, at the point that they have moved (or planned to move) to iBatis, which is closer to SQL. Please note that I'm not against Hibernate. I repeat, I've been using it with no specific problems and many of my customers are - but because we have chosen to give up with some of the advanced features (e.g. lazy collections and such). In the end, great amounts of code have been written in the application to supply the missing features. In the end, I still prefer it to other approaches, but generally speaking, it's extremely likely that in a very complex application you can't use the whole "magics" that Hibernate provides in theory. That's why I think it's really the bad example for supporting the assertion - that I support for other reasons - that things have greatly improved. Back to the original topic, I think that the pessimistic guys are not considering a point: twenty years ago the average software project was *much* simpler than today. I mean, there were not Internet, the related massive scalability issues, the related security technologies and ABOVE ALL the life cycle was more regular, that is you there were more chances that the original specs were the final ones, while today is almost impossible (in other words, today specs on evolution and flexibility are much more complex). So even though we put the same effort on the average project than twenty years ago, it's a proof that technology has really improved since the average complexity today is MUCH higher. - -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." java.net/blog/fabriziogiudici - www.tidalwave.it/people fabrizio.giud...@tidalwave.it -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8pmgACgkQeDweFqgUGxdJLACePJAhtR5jP6J4VCfvp3oZFRa8 MFsAn0IND66Qy4Xt1s5Zn4BkyvBn7znK =aXR0 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
