[EJB 3.0] - Re: Stateless Session Beans - Static Variables - Concurrency
by ColinEberhardt
There are a couple of consequences to your method of caching data:
1. You certainly will hit concurrency issues. Your container will most likely hold a pool of SLSB instances, enabling it to service requests from a number of client. These request may result in concurrent access of your cache data.
2. This will certainly not work in a clustered environment. The different container instances will run under different JVMs. Static data is only shared between classes runnign in the same JVM.
SLSB are simply not designed to be used in this way. The JEE5 framework is designed in such a way that developers do not have to worry about the mechanics of concurrent accesses or clustering. You are breeaking this!
Are you sure that you need this cache which you have implemented? Have you executed performance tests and found that the system is slow?
Optimising for performance too early results in ver porr designs.
Are you aware fo the fact that Hibernate offers 3 levels of caching? I should imagine that your data will sit quite happily within the Hibernate L2 cache and that your database will not be repeatedly hit.
If you do test your system and find that the performance is poor, your first strtegy shoud be to try tuning teh system, not to hacjk together a cache!
Regards,
Colin E.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028861#4028861
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028861
19Â years, 1Â month
[JBoss Seam] - Re: s:SelectDate not popup
by bsmithjj
Hello,
I'm still having trouble getting the <s:selectDate> to work with night builds of Seam (later than the 1.2.0 patch). As I reread postings like this and the JIRA issues I have tried to file repeatedly over this, I want to make the following request to the Seam developers - first, let's look at this:
"cavani" wrote :
|
| This files needed from Booking:
|
| css/date.css
|
| img/cal-next.png
| img/cal-prev.png
| img/input.bg.gif
|
| on of HTML:
|
|
Now, in addition to the Seam Resource Servlet, the <s:selectDate> requires the files above. So instead of constantly asking users of the framework to pull files in from the example, how about just improving <s:selectDate> so that any required resources are provided by the Seam Resource Servlet? And, for the purposes of skinning, you can come up with some solution that allows the developer to override the defaults? Speaking as someone who is actively using the framework with a goal of getting to a production release, I don't typically diff the examples with each release of Seam - mainly, I look at the documentation.
I ask this because I've been using Seam for nearly 8 months on a major project - now, I only pick up a new version of Seam when needed (for example, I need fixes in the seam email component....). It's an unpleasant surprise when a feature like s:selectDate stops working - I've learned how to use it twice now, and with the nightly builds, I can't even get it to work. I've also learned from discussions in the JIRA issues that s:selectDate may in fact be deprecated/dropped in future Seam releases - if that's the case, then why so much change around s:selectDate?
Thanks,
Brad Smith
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028859#4028859
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028859
19Â years, 1Â month
[Installation, Configuration & Deployment] - Boot logging question
by rachmatowiczï¼ jboss.com
Hi
I'm trying to get a trace of org.jboss.Shutdown and org.jboss.server.system.Server. I've found that JBoss's use of log4j is split between boot logging (where you configure log4j via a log4j.properties file in run.jar), server logging (where you configure log4j via server//conf/jboss-log4j.xml and application logging (where you configure log4j via log4j.properties in WEB-INF/classes).
I have extraced logj4-trace.properties from run.jar and modified it to add an appender called SHUTDOWN and two categories to pickup the trace messages i'm interested in:
log4j.rootCategory=TRACE#org.jboss.logging.XLevel, FILE, CONSOLE
log4j.category.org.jboss.Shutdown=TRACE#org.jboss.logging.XLevel, SHUTDOWN
log4j.category.org.jboss.system.server.Server=TRACE#org.jboss.logging.XLevel, SHUTDOWN
### A bootstrap file appender
log4j.appender.FILE=org.jboss.logging.appender.FileAppender
log4j.appender.FILE.File=${jboss.server.log.dir}/boot.log
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
log4j.appender.FILE.Append=false
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Target=System.out
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
log4j.appender.SHUTDOWN=org.jboss.logging.appender.FileAppender
log4j.appender.SHUTDOWN.File=${jboss.server.log.dir}/shutdown.log
log4j.appender.SHUTDOWN.layout=org.apache.log4j.PatternLayout
log4j.appender.SHUTDOWN.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
log4j.appender.SHUTDOWN.Append=false
I start the server with
./run.sh -Dlog4j.configuration=log4j-trace.properties -c default
and the trace statements appear on the console and boot log, but there is no log file shutdown.log created.
I'm also getting occasional error messages like:
log4j:WARN No appenders could be found for logger (org.jboss.mx.loading.RepositoryClassLoader).
log4j:WARN Please initialize the log4j system properly.
My question:
1. is there anything obviously wrong with this log4j-trace.properties file which I am missing and which explains why the shutdown.log file is not getting created
2. what is the best way to trap log.trace() messages on org.jboss.Shutdown and org.jboss.system.server.Server.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028857#4028857
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028857
19Â years, 1Â month