Hi all, I was thinking about James' remark regarding the fact that we should work on a generic Transaction Service utility for Hivemind. This service would have implementations for JDBC connections/transactions, JTA transactions, Hibernate transactions... I started to have some reflection about that and dramatically refactored code that I had started to write for Hibernate support. This is quite a lot of work actually!
About Hibernate I was wondering about one important point: - outside the context of JTA, does it make sense to allow creating more than one SessionFactory (ie, more than one DB to connect to)? If so, then how should we manage transactions? I mean, if your code works at the same time with 2 sessions (referencing 2 different databases), when the time comes for the transaction service to commit the work, what should it do to commit 2 transactions independently of one another (no JTA), what should happen in case of a problem? - wouldn't it sound better (I mean, more logical) to restrict usage of only one SessionFactory when there is no JTA transaction service available? Actually, the same question applies as well to JDBC: should we allow having more than one DataSource in the system? Some ideas about that? If I have more time this week-end I will try to come up with a first version including the following: - TransactionService interface + dependent classes (the "transaction framework"...) - JdbcTransactionService + simple example - HibernateTransactionService (draft) in "mono-SessionFactory" + simple example It could be ready for upload during next week. JTA will certainly not come until much later (I have to self-learn about it first and find out a JTA Manager that can work out of the box (ie, not inside a complete EJB container)). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
