You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by David Sitsky <si...@users.sourceforge.net> on 2001/10/22 14:14:23 UTC
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Concurrent access to James's message database
Posted by Serge Knystautas <se...@lokitech.com>.
Someone was suggesting storing these locks in a DB, which can be problematic
if JAMES gets restarted and the threads doing the locking are killed without
releasing locks, but you could get around this with timeouts on locks.
Would slow performance down storing locking information to the database, but
for people who needed this behavior, would be nice
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: <ja...@jakarta.apache.org>
Sent: Monday, October 22, 2001 8:50 AM
Subject: RE: Concurrent access to James's message database
> 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:sits@users.sourceforge.net]
> > Sent: Monday, October 22, 2001 1:14 PM
> > To: james-user@jakarta.apache.org
> > 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: james-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Concurrent access to James's message database
Posted by Danny Angus <da...@thought.co.uk>.
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:sits@users.sourceforge.net]
> Sent: Monday, October 22, 2001 1:14 PM
> To: james-user@jakarta.apache.org
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org