on 10/22/01 11:13 AM, Matthew Kennedy at [EMAIL PROTECTED] wrote: > Why was Berkeley DB chosen for caching when a RDBMS (mysql in this case) > was already being used?
It's faster and less resource-intensive for this kind of thing. We just wanted a really fast persistent hash, and didn't need SQL or relational concepts. > Secondly, I've worked on a good-sized commerce site with > mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end > of the site involves several standalone perl programs running as > daemons. What's even worse is; most of them have to sit in poll/wait > loops waiting on message from external systems (such as pop3 servers, > ccvs etc.) It sounds like the limitation there is that you're interfacing with systems that can't notify you when something new happens. That's not Perl's fault. If you wrote your daemons in Java alpahabet soup, they'd still have to poll the pop3 server. > For comparions, a nice aspect of j2ee applications IMHO is the > "application server" tends to be more general. ie. the application > server is not just the web server (as it is with mod_perl). I've found > j2ee features such as message beans, queues and such especially useful > for back-end work. For these reasons, I personally don't buy the > argument that mod_perl makes an effective application server for a good > sized task (your mileage will vary no doubt ;). I guess it all depends on what you think "application server" means. In our case, it was a server that ran code persistently, which supported an HTTP interface. It wasn't our front-end web server, and we could run anything we wanted to in it. Lots of people implement reliable queues in Perl. They generally use something like an RDBMS or Berkeley DB (which has a queue option) for the backing store. Many JMS implementations use an RDBMS for all the hard stuff as well. > So again, I'm curious, what does the eToys.com site back-end stuff look > like? The web site part that was discussed in the article ended at the Oracle database. There was a system built on Oracle's queuing technology that replicated orders to a backend system for processing. I believe the last revision of that was largely in PL/SQL. I don't know much about it, since there was an entirely different team working on it. - Perrin
