Read only access is trivial, as long as you are aware that the records may change without warning, and that james uses an internal lock to which you won't have access.
That also points out the only (as far as I can tell) issue with r/w access. On the other hand I suppose it depends what you are trying to do whether or not the lock is relevant, I gather its primary function is to prevent James performing an action on a message, before a previous action has had time to change the message state, in which case if your actions aren't going to start or suffer from a similar race condition, you can probably get by without it. It might be worth investigating extending JDBCMailRepository so that you can access James' internal locks, if you have problems. d. > -----Original Message----- > From: David Sitsky [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 22, 2001 1:14 PM > To: [EMAIL PROTECTED] > Subject: Concurrent access to James's message database > > > G'day, > > If I were to use James as a mail server and as a database > repository for mail > messages, are there any issues/gotchas associated with accessing > the Message > table directly? I have a set of requirements where sometimes it > is necessary > to perform large high-volume queries of stored messages, and it > would be very > convenient/desriable if I could do straight SQL queries on the > Message table. > I'm assuming there shouldn't be any problem, but wanted to check > to make sure. > > I imagine most of these queries would be read-only. What are the > issues if > the messages themselves could be changed? Should this only be > safely done > through the JavaMail API? > > Thanks in advance for any advice. > > Cheers, > David > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
