trebor iksrazal wrote: > --- Steve Brewin <[EMAIL PROTECTED]> wrote: > > trebor iksrazal wrote: > > > > > Wouldn't a Mailet > > > block, only returning after a db write? If the db > > is > > > down, and there were a lot of timeouts for a lot > > of > > > messages, would a JMS queue processed in > > intervals, > > > via extending GenericMailet, help? My idea is to > > use > > > Message-driven beans and entity beans to write > > emails > > > to the db. > > > > In order to be sure that messages were not lost, the > > JMS queue would need to > > be persistent. Persistence would most likley be > > provided by storing the JMS > > message in a database. So, rather than circumventing > > any database bottleneck > > problems, we would be increasing the database > > activity, making such problems > > more likely. > > > > James runs in an Avalon container which is not J2EE > > compatible - there are > > no message driven or entity beans to use. > > > > -- Steve > > Thanks for the response. You could be right, but I did > do some research.
Maybe I misunderstood your question. I rather thought that you were suggesting internal changes to how James' repository is configured. If you are talking about using a mailet to provide a JMS feed out of James and using a MessageDriven Bean within an external J2EE application to read messages from JMS, then that is a good way to go. You have nicely decoupled the the concerns of the mail server from those of your business application and have the basis of a highly scalable distributed solution. > I'm using jboss, which seems to do jms persistence via > a log file: Most JMS implementations will - for testing purposes only - it doesn't scale, use a database in production! -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
