On 2001.11.13 00:13:54 -0500 Hiram Chirino wrote: > > 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.
This is only a problem with a non-xa driver. With an xa driver, unlimited numbers of transactions can use the same connection serially. Anyone actually using transactions with jms is going to need a non-toy db also supporting xa, so I don't see this as a limitation except possibly for easy free testing in an all java environment. But then, right now the xa tests in the testsuite fail for lack of an xa db. The (xa capable) firebird jca-jdbc driver is probably nearly far enough along to work for this. thanks david jencks > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
