I looked too. On 2001.11.12 23:22:27 -0500 Loren Rosen wrote: > I've been looking a bit at the jboss mq persistance code, and I have > some questions. I'll state some of them from a user perspective, but my > motivation is as a developer; that is, to address some of the 'problems' > or 'limitations' these questions may uncover. > > * Different DBMS system support: I realize the current schema is pretty > simple, but nevertheless I think it's inevitible that you're going to > want tweaks for different database servers, for performance reasons if > nothing else. > > * Performance tuning/scalability: has any work been done to address > potential bottlenecks for high message throughput, large numbers of > queues or topics, etc.?
There's a recent start at a message cache. It appears to me to duplicate the pm, so I suspect there is room for a great deal of improvement here. > > * recovery robustness: recovery is a tricky thing since there's so many > possible ways things can fail. What's been done to think > about/test-for/defend-against all the possibilities? XAResource.recover is not implemented. I think little has been done. The jdbc pm doesn't even make an attempt to recover from any failure when there is an open transaction. > > * two-phase commit: Is two-phase commit (XA) supported? I didn't see > anything explicitly in the code, but pehaps I haven't yet read it > carefully enough. I also am unclear about this. I have a hard time convincing myself it works in the absence of good tests. > > * architecture: I haven't thought deeply about the trade-offs, but at > first look it seems odd to create a transaction log table in a rdms, > given that they can do the logging for you behind the scenes. > Among the odd features of the jdbc pm is that it requires the db connections it uses to have autocommit = true. As far as I can tell this is undocumented. I did a little (very little) thinking about this and wondered if the following would be plausible: 1. modify PersistenceManager interface to expose an XAResource interface, used for all transaction control. 2. For jdbc pm, expose the XAResource from the (jca wrapped) XA db connection. For other pm, write whatever is appropriate. 3. Expose the XAResource from the PM through the XASession or the jms ra. This will allow 1 phase commit optimization for a transaction involving both the db and jms, at least if the transaction is entirely on the same server. (jms server on same vm as beans) 4. I'm not sure if it is necessary to register a synchronization with the tm to tell the stuff above the pm to flush cached results to the pm before commit starts. I suspect not but I'm not sure. Something like this seems to be called a caching manager in the jca spec. I'm unlikely to have time to implement any of these soon but I like thinking about them. Thanks David Jencks > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
