Yes, I have done some simple stuff with two standalone portal server (jboss-portal.sar) backed by one database and mod_jk in front. I did not encounter any problem but I think it very well depends on the use case. I will be interested in knowing what you find.
thanks for the info.
I don't see why this would cause a problem.
But want to make sure, before to go further.
Someone reported a problem about that, but I can't see why.
I will investigate more about the problem on monday.
I will report the info, if it may be interesting.
With one database and multiple JBoss instances, I am facing following issue:
1)Changes done from Admin portlet of one instance does not reflect on other instance. The changes are applied only after restart of the server.
I understand that this problem is because of Hibernate configuration. But, can some one please guide me, How to resolve this issue?
I don't think it's a good idea to have multiple instances of portal running with one DB. You should use clustered version of portal.
In a non clustered version, you would have to flush any DB changes right away in Hibernate which defeats the purpose of having session.
What I get from your reply is that if, I have to use a deployment architecture of multiple instances and one database, I will have to put the logic in source code of admin portlet to flush any DB changes right away.
Is there any configuration in JBoss portal that I can use to do so or, It will be a code level change?
Yes, that comes from the Hibernate cache.
JBP1 have loaded the instance definition, so it is in cache.
JBP2 have loaded the instance definition, so it is in cache.
Change is made on the instance, with JBP1.
JBP1 have saved the instance definition, so the cache have updated it's instance too.
JBP2 still uses the cached one... hence the change does not appear.
With a cluster, Hibernate synchronizes it's cache... so it works fine.
I guess you may find a way to clear all the cache (from JMX console may be). But I don't know how.
Note on thing : on startup, all the contents of the CMS are loaded in the hibernate cache. This is for performance, when using the CMS. so make sure not to clear this cache. I guess they are separate, but not sure.
when I asked the question, I had in mind this : only for prod, not changing things in the portal.
neither the portal definition, nor the CMS.
At this time, the portal did not used the JBPM. It is used for user registration now.
so this may also make some problem with only one DB. Should not, but make sure before to go further.
And, by the way : on my opinion, the Admin GUI is nice, but it should be used only for prototyping, and making quick demo.
and nice for newbee to have a sexy software out of the box.
very good to get familiar with the portal.
but for prod, especially if you have to instances, I would recommend only to use the XML descriptor files.
using the Admin GUI drives you to some troubles.
main cons :
- if you have two developpers working on two different parts of the portal : how do you merge their changes ?
with xml files, you can do a merge (with svn or cvs)... or also the merge is imediate if they work on two different wars.
- in XML files if you work on a page, window, instance or portlet, by deleting one or even just changing the name, then the former one remains in the database. it is not suppressed.
So as soon as you start with the GUI, you cannot touch the xml file, without many trouble. You may have some remaining objects in the portal configuration. And deleting them "a la mano" in the GUI is quite boredom.
It is much more easy to drop all the tables, and relaunch the portal : all is rebuilt from the xml.
- if you want to start from a new JBP configuration (from dev to testing, then to prod), it is quite heavy to dump and restore the database to the new configuration.
Portal is producing a new version oftenly.
It is much more work, and much more risk with the GUI + database.
so... for a heavy portal, that goes to prod, I recommend that you use the XML files.
Hope it helps,
I just saw your new question.
yes, the idea is that : "put the logic in source code of admin portlet"
but... bouh !
what when you update for new version of portal.
Transfert the code ?
many risks of bugs.
lot of work.
You can also make a porlet, with one big button for : "update all config".
that would do the clear.
And think, after each modification work, to press it.
By the way : I'm not sure, but it is not a question of flush.
Flush : JBP1 hibernate pushes the change in the database.
but JBP2 won't fetch the new version. It does not know it have been changed "behind him".
That is one of the tricky thing of hibernate : use only hibernate... or becarefull with the cache side effects.
You need to tell the JBP2 cache : "the cache instances are dirty... don't use them anymore... go to the database to refresh them".
don't know exactly where to trigger this in Hibernate, that's why I call it "clear the cache".
may be use the cluster ?
with each version of portal, you have a download of a pre configured portal for cluster. ready to use.
with doc explaining how to etc...
you cannot use cluster ?
I have seen the case (running in prod) in a company.
6 JBP, only one database, no cluster.
and many troubles...
also, same thing, the webmaster was changing the portal with the GUI, on one machine. Then, it had a portlet with "the big button", to copy (batch at night) the database to the prod database, and relaunch the JBP.
so the next morning, the change was on.
they faced many problems, sides effects, constraints...
well... for prod, with several JBP needed... this is not the best way to do.
the only use case constraint that would allow this : only with a portal that change very very seldomly.
Then, I guess, you don't really need the Admin GUI. you can prepare things in the XML files.
I think Jboss Portal internally uses Hibernate Query Cache/Second level cache. Instead is it possible to enable lazy loading. Though i have not yet tested commenting query and second level cache.
In case of lazy loading it may help to get rid of this issue of clustering of hibernate cache.
Thomas / Prabhat, any comments on this.
Yes, JBoss uses second level cache in Hibernate and implementation differs depending on clustered and non clustered version.
We do not test multiple portal servers (non clustered) sharing one DB instance and strongly suggest not to go that route.