That was something I was asking myself some days ago: why i would use JBoss?
On Wed, 2002-09-04 at 20:06, Eddie Bush wrote: > 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]> > -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Faculdade Ritter dos Reis www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303328 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
