Yes, I think it's a well-established practice to use a common database as a store in a distributed system.provided that the database can handle the volume. since mail is well suited to load balancing across many, simple systems it is easy to envision an implementation whereby you do not have the horsepower in a db to keep up with the mail volume; a common problem making DBs the achilles heel of most high throughput systems.
Low end databases often lead to a single point of failure. Enterprise grade databases do not have single points of failure, which is why people who such infrastruture requirements pay such big bucks.
name your favorite and i bet you i can kill it with *one* pepsi :o)
Bounces don't need to be processed in real-time... we can't control how long it takes the remote server to handle the response, so if a resource is temporarily unavailable, the message sits in a spool unprocessed.a) i would suggest that determining 'temporarily unavailable' is non trivial (not to mention that it would require that that database updates {logging} are blocking calls -- yikes!)
b) the issue of relative performance remains. how long it takes to process the bounces is moot if a database entity is incapable of keeping up with the volume of mail generated. this is why it is common for systems that must maintain state in a distributed fashion do so by transmitting the updates to remotely stored [local] repositories (routers and firewalls handling IP state info being a good example.)
b
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
