Ask questions and see you at November, 7th at 6.PM. CET: http://www.ustream.tv/channel/adambien
Also see archives: airhacks.tv
Ask questions and see you at November, 7th at 6.PM. CET: http://www.ustream.tv/channel/adambien
Also see archives: airhacks.tv
Just a small comment on "JDBC vs ORM" subject (after seeing the podcast):
We have worked on a huge statistical analysis system, where there were KPI graphs for the clients. One of the KPI graphs involved querying about 5-10M records from the database (it was a table with like 700M records). The select speed and transport to application server was nothing (we have been using a very good performing MS SQL server, and we only queried the table by the unique indexes) ~ 1-10 sec.
BUT: processing this amount of data was very slow from JPA side (it doesn't matter if you are using hibernate or eclipselink), since it is instantiating a huge amount of objects through reflection. So, using JDBC was the only option here, if we wanted to process all those records in acceptable time. To my experience, there is a record number, that is the dividing line between JPA and JDBC. So if your queries have no more than 1000-10000 records, you can go safely with JPA. In any other case, just rather use JDBC.
One of my previous colleagues had an experience with querying more records, but he stated, that above selecting 250000 records it had a huge performance impact on hibernate.
What does mean SERIALIZABLE in transaction context?