[
http://www.stripesframework.org/jira/browse/STS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11974#action_11974
]
Nikolaos commented on STS-747:
------------------------------
Aleksander,
> I have (maybe because my project is quite unusual). We have a lot of simple
> applications, which use the same database, and few common tables. So, for
> example, the hibernate is used as common library (to utilize common cache for
> all of the applications).
Okay. So I imagine you know this... but out of box Hibernate doesn't do much
to help in the case of system wide caching. Hibernates has a 1st level and 2nd
level cache. in fact, OOB first level cache by default associates with the
session object to eliminate duplicate transactions within the SAME session...
so that is of ZERO help system wide. Second level caching can assist system
wide.
So what have you configured for your Hibernate caches?
Also even if you use 2nd level caching... separate caches may in fact be more
performant as cache spaces are limited and their should be less flushing of
useful data (of course the compromise here is the classic speed vs. memory)...
i.e. if the number of Applications is large enough and there are lots of things
to cache it is not impossible that your system ends up defeating the cache it
depends on due to limited resources and MANY things to cache and things getting
flushed before being re-used. Of course if your caches are sufficiently large
enough then no worries... but people don't always consider this potential
negative outcome when not properly sizing systems and primarily focusing on the
Application.
> There are also few singletons which are used by the applications, which makes
> them "system wide" singletons. And to achieve that they have to be put in a
> shared library. Do you think that shared libraries could be avoided in such a
> case?
Personally I do think its unnecessary... unless we are talking about some
extreme case where memory may be an issue... but even then breaking out the
functionality into a Services tier is what I would suggest. In fact, it sounds
like what you describe is a baked-in Services tier (why do I say baked-in...
read on... :-)
I'll give you what we do today and plan on doing in the future as our
Application grows:
Today we have an RP tier and 3 UI Apps (web, mobile and admin) leveraging a
Service tier which makes calls through our Data Access layer and onto our DB.
The services layer is simply a JAR that is bundled with each of the 3 UI Apps
today. The services layer (like others) is plugged in via Spring. Yes - each
web app will have its own local Service layer caches. We use multiple App
server instances and multiple servers in the UI / Services layer (and will most
likely leverage memched or hibernate-memcached as a caching layer).
In the future, when our App experiences growth we will move the Service tier
out to another set of servers and via Spring simply wire in the stubs that make
Web Service calls to the Services layer with only the addition of code and
modification of Spring XML. We will use multiple App server instances and
multiple servers in the UI / Services layer.
In your case, your Services tier is baked-in to the web container and spans
multiple web apps through a mechanism offered by the web container. Personally
I don't see the benefit of such a design and I can only envision the need for
re-factoring and re-packaging of code if there is sufficient growth.
Application Architecture is obviously not black and white... but those are my
views... in addition to what I have said earlier... YMMV :-)
> ActionBean names from different applications conflict with each other.
> ----------------------------------------------------------------------
>
> Key: STS-747
> URL: http://www.stripesframework.org/jira/browse/STS-747
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5.3
> Environment: Tomcat 5.5, Stripes deployed as shared library.
> Reporter: Aleksander Zarczynski
>
> I have two applications deployed on the Tomcat server, with Stripes deployed
> as a shared library. Both contain ActionBeans with the same names. The name
> patterns are following:
> net.company.app1.action.SomeActionBean
> net.company.app2.action.SomeActionBean
> The applications are deployed in different contexts: app1 and app2. So, the
> beans are accessible under following urls (relative to server root):
> /app1/Some.action
> /app2/Some.action
> The problem is that only one of the ActionBeans are accessible at the same
> time. If app2 is deployed latter, its ActionBean is resolved correctly, but
> any request to /app1/Some.action is resolved also to /app2/Some.action.
> Analogical problem occurs when app1 is deployed after app2.
> I found following comment in the UrlBindingFactory.addBinding() method:
> "Search for a class that has already been added with the same name as the
> class being added now. If one is found then remove its information first and
> then proceed with adding it. I know this is not technically correct because
> two classes from two different class loaders can have the same name, but this
> feature is valuable for extensions that reload classes and I consider it
> highly unlikely to be a problem in practice."
> I'm not familiar with the code enough to be sure that this design decision is
> a reason of the problem (however, the Tomcat uses different class loader for
> each application). But if so, it's also quite big limitation imposed on
> applications internal architecture. Maybe the context path could be also
> taken into account in internal structures of the dispatcher?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
