Hi Loren!
>From: Loren Rosen <[EMAIL PROTECTED]> >To: "[EMAIL PROTECTED]" ><[EMAIL PROTECTED]> >Subject: [JBoss-dev] jbossmq: persistance implementation questions >Date: Mon, 12 Nov 2001 20:22:27 -0800 > >I've been looking a bit at the jboss mq persistence 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 inevitable that you're going to >want tweaks for different database servers, for performance reasons if >nothing else. > I guess will will make the code more abstract as we start supporting more databases. If a DBMS is different enough from the basic implementation, we could always create a new Persistence Manager just for that case. >* Performance tuning/scalability: has any work been done to address >potential bottlenecks for high message throughput, large numbers of >queues or topics, etc.? > Work has gone into making reading/writing from storage more efficient. I don't think we have profiled the system enough yet to find out where the bottle necks are. >* 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? > Basic recovery test have been succeeding. It's hard to automate failure testing. More code review would be good in this area to see if we are missing anything. >* 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. > We do have some basic support for XA. In phase 1 we store all message activity to persistent storage. In the seconds phase we mark the transaction as committed. Kinda simple since in a messaging system, we have fewer problems that could cause the prepare to fail (we don't need to get any locks and such). >* 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. > Not really, if we were to tie down every JMS session (transaction context) to a database connection, we might run out of database connection quickly. That is why we manage the 2 phase commit and don't delegate that work to the database XAResource. All the work that is done on the database is not considered to be transacted so the transaction log is used to be able to rollback incomplete JMS transactions. Regards, Hiram _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
