Well, I started the run again with added logging and found the following:
- The sending component was pulling fewer entries from the DB than there were rows.
- All of the pulled data was being sent.
- All of the sent data was ending up in the JBoss JMS queue that the MDB subscribed to.
- All of the data in the queue was being pulled by the MDB.
- About half of the data pulled didn't have a corresponding entry in the DB, and therefore didn't result in a valid warehouse entry being created.
Well, the "infection" point for the bug was clearly the client, but that didn't make any sense. The code that loaded the objects from the DB basically boiled down to:
HibernateTemplate ht = (HibernateTemplate)appContext.getBean("hibernateTemplate");
List = ht.loadAll(Foo.class);
Here
ht is an instance of org.springframework.orm.hibernate3.HibernateTemplate, and loadAll(Foo.class) should have returned a list of all the instances of Foo in the DB. For some reason however it returned 2/3 as many instances as there were rows, and about half of those had IDs that didn't match the value in the DB.Going deeper into the rathole I tried making a simple set of JDBC calls against the underlying
org.springframework.jdbc.datasource.DriverManagerDataSource and got a java.sql.ResultSet back that made even less sense.In the end I went back to basics and pulled the IDs directly out of the DB using straight JDBC, and now I have a full warehouse as the JMS and EJB3-managed entities on the server worked fine. Nonetheless, I'm incredibly confused by what happened with the Spring/Hibernate setup, and a little worried about what other issues may have gotten by the unit tests, as this only cropped up when I tried working with data sets in excess of 16,000 entries. If anyone out there has any ideas, please let me know.

No comments:
Post a Comment