SOA support in IBM has improved a lot in their current release WESB7.x compared with earlier one, however it still is mired with issues that cause frustration. We were at v6.x struggling to figure out why's and where's of our friendly WID tool, a resource gobbler that would bring your development machine to its knees, when sudden developments beyond our control forced us to move to v7.x. The oddity being our Dev, staging and prod environments were to be rebuilt rather than running an upgrade raising eyebrows and suspicions.
Instead of building from Dev-> QA ->Staging->Prod in that order, our learned friends chose the reverse order so that development was not impacted. They were assuming repeatable and reliable behavior of topology images from a tool they had no prior experience. Alas, surprise in store, all went well in Prod but when executing the same instructions in Staging we noticed weird issues pointing to SpringFramework and J2C transactions. The surprise initially was not the failure issues but the springframework in IBM, our corporate folks always shunned from open source tools and were a big fan of IBM, EJB, et al and vehemently opposed introducing Spring. Now here it is backed by the big blue spewing errors that no one can make sense.
After couple of days of research the issue was nailed to datasources "jdbc/mediationMessageLog" and "jdbc/WPSDB", where both share connections and enlist in XA transaction. For some reason enlistment was failing even though XA was enabled at datasource and backend. Once we changed datasource property to use non-sharable and non transactional connection the problem went away. Ofcourse, as a side effect we were not able to use messagelog primitive which uses jdbc/mediationMessageLog for database logging. No big deal, we used trace log as a workaround to meet deadlines while waiting on IBM to figure out this anomaly.
No comments:
Post a Comment