Comments in-line. Shapira, Yoav wrote:
>Hi, >Perhaps putting the common code, e.g. the singleton, in /common/lib will >work for you? > >Yoav Shapira >Millennium ChemInformatics > >>>A "best practices" question: >>> >>>What is the best way of sharing a single, changeable copy of common >>>information across multiple servlets? >>> >>> >>>Example Scenario: >>> >>>Using two servlets (webdav and cocoon), I need to share common >>> >>information >> >>>between them. >>> >>>There are two choices for how to host the servlets, each of which >>> >affects > >>>the options for sharing info: >>> >>>- host the servlets in different contexts (a likely requirement >>>if security >>>constraints differ) >>> >>>- host the servlets in the same context. >>> >>> >>>Then, within each servlet you could share the information through: >>>- singleton classes >>> + pro: conceptually simple >>> + con: singleton pattern isn't bulletproof >>> + con: threading issues? >>> + con: lifecyle issues (can't use servlet destroy() if have multiple >>>servlets) >>> What threading issues would you have that synchronization wouldn't cure? It depends on the nature of your data/how volatile it is. If it's especially volatile, the singleton could (conceivably - you'd have to test to see) become a bottleneck. If most of your access is read-only, I don't see how this is an issue. You have to sit down and take a look at who (and how many whos) can modify the data. How many would (really) do it simultaneously? I'd highly recommend synchronizing your mutators in either case. The fewer people that have the ability to update, the less likely this will ever become a bottleneck. >>>- avalon roles >>> + pro: convenient, correct lifecycle management >>> + pro: using avalon in other apps (James) in same JVM could also >>>share info >>> + con: poolable (e.g. multiple instances) and not the same as >>> >singleton > Not familiar with them. >>>- context attributes >>> + pro: conceptually simple, no singleton coding necessary >>> + con: HTTP specific, information can't be shared with non TC app >>> >>(James) >> >>> + con: can't share across contexts, all servlets must live in same >>> >>webapp >> *nod* ... and? >>>- enterprise javabeans >>> + pro: managed >>> + con: requires J2EE server? >>> Ok, so use JBoss instead of TC (I think JBoss actually includes TC). I'm not very familiar with this either. >>>1) Are there other options I'm missing? >>> How about keeping the data in a database and devising a cache mechanism that will refresh the cash at a user-defined interval? You've just solved your concurrent updates problem, assuming you use a DMBS that thinks ACID is good (ie MySQL would not be my first choice --- PostgreSQL is a good open-source solution). >>>2) What have people found to be the best pattern? >>> I think that would depend entirely on your given application :-) My general rule of thumb is to introduce no more complexity than I absolutely have to in order to acheive the required functionality. For a small application, the singleton would (most likely) be fine. For a large one, EJBs maybe (I'm totally unfamiliar with them, so I can't say with any authority). I would probably, on a large-scale project requiring a lot of simultaneous updates of cached data, use a database. >>>3) Besides the servlet 2.3 reference docs and O'Reilly books, can >>> >anyone > >>>recommend reading material that includes these issues (most >>> >introductory > >>>books cover the same 'your first webapp' type of material). >>> Not off-hand -- nope. Sorry :-( >>>Thanks in advance for your opinion, >>>Per >>> No problem -- that'll be $9.95, please. Would you like fries with that? Just kidding ... :-) Maybe, if nothing else, I'll bump your post up and someone more authoritative will pipe up. Regards, Eddie -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
