[JBoss-user] does jboss come with an email server?
does jboss come with an email server? My guess is not, but would like to see if anyone can confirm. Thanks, Derek
[JBoss-user] Re: Re: Concurrency problem
Yes I do have a more specific problem which I had posted earlier but there didn't seem to be any reply for that. I am sending it again.. Hi, I am using Jboss3.0 with Tomcat 4.0.3. I am also using Castor. During our development process, we came across lot of castor bugs which we kept on fixing and presently have a robust application environment for a SINGLE user application. However, in case of simultaneous access, the application fails and JBOSS throws CONCURRENCY error. How can I avoid this ? Any pointers ? I am not using any transaction attribute which means the default transaction attribute [ "Requires" ] is being used. Is the concurrency problem due to this ? Do I need to make transaction attribute [ "RequiresNew" ] ?? Regards, Arijit The J2EE specifications contain lots of information about concurrency-related issues. Perhaps you have a more specific question? Benjamin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson Cargnin - SICREDI Serviços wrote: Dain Sundstrom wrote: Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. what I really mean was that cmp would be alot more usable : ) by the way, we are in in a doubt about a point of architecture : as i discussed before somew time ago, in a very big system (like the financial one i'm on) there is the need to separate the modules of it, like one for accounting, other for savings, etc. And each one would need to talk with a couple of others. The problem : to separate and allowing those to be separate deployable, you would have to get rid of cmr's and make the modules talk with each other through session facades. In this case even with cmr read-ahead would do nothing to avoid the n*cmr needed to access each entity. And worse, how could I manage the constraints between 2 related (and module separated) entities? one would need to consult the dependent module (via session facade) to see if it could be deleted... I don't know what going be the solution, throwing entities away, or making up a monolitic system using cmr. any suggestions? Yes, in 4.0 there will be an abstraction layer between the cmp view of the world and the physical storage. This means that it will be possible to map several cmp beans in different applications to the same store. The real trick is keeping the caches in sync and this is where the new invalidation code comes into play. Another change is will be the introduction of a domain concept above applications. Applications in the same domain will be able to share a common store manager. These big architectural changes are designed to make this type of application possible. (Note: all of these, except the invalidation code, are still in the concept stage of development) -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] missing parent entity in 1-* CMR causes trouble
Hi list,
While iterating through a Collection of children in a one-to-many CMR that I
obtained by a child bean finder method, I use the child's CMR accessor to get
a reference to the parent entity, and then get some of the parent fields.
However, if the parent is non-existent (these data are from two pre-existing
databases where the child set is older than the parent set, so many of the
older children are orphans) I get a javax.ejb.NoSuchObjectLocalException that
appears to be uncatchable from my code. I just want to be able to catch the
exception where the parent is not found for one of the children, but keep
iterating through the rest of the children. But the above-mentioned
exception causes a TransactionRolledbackLocalException which invalidates
everything and causes the rest of the iteration to fail.
here is a sample of the code (csr
LocalCSRequest csr = (LocalCSRequest)i.next();
...
CSRViewObject vo = new CSRViewObject();
vo.status = csr.getStatus();
try {
LocalJob job = csr.getJob(); //** THIS IS THE PARENT ENTITY
ACCESSOR **
vo.job = job.getJobID(); //** THIS WHERE THE EXCEPTION IS
THROWN **
}
// ** THESE DON'T GET CAUGHT **
catch(NoSuchObjectLocalException nsole) {
System.err.println("No Job entity found for csr " +
csr.getCSRequestID());
}
catch(Exception e) {
System.err.println("No Job found for csr " +
csr.getCSRequestID() +
" exception is type " + e.getClass());
}
return vo;
here is the end of the stack trace:
[org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException,
causedBy:
javax.ejb.NoSuchObjectLocalException: Entity not found: primaryKey=21026
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:181)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178)
(etc.)
Does anyone have any thoughts as to why my code won't catch the
NoSuchObjectLocalException ? Maybe I'm missing something completely obvious.
Thanks in advance for any advice.
Justin
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: transactions in stateless session bean.
Rob, I solved my problem. Stupid mistake, which was what I thought it would be: I had in the dd set to 'Bean' rather than 'Container'. I must've copy-n-pasted some of the dd content from another session bean and forgot to change it. I guess that's what I deserve for not using xdoclet on this project. Hope this helps. Justin > I'm seeing something almost identical in a unit test I have. My code is > slightly different than yours, but not by much. Basically, I create add > an object to another (parent) object and when I try to fetch it by > primary key and then ask for the child collection I get the same error. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Dain Sundstrom wrote: Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. what I really mean was that cmp would be alot more usable : ) by the way, we are in in a doubt about a point of architecture : as i discussed before somew time ago, in a very big system (like the financial one i'm on) there is the need to separate the modules of it, like one for accounting, other for savings, etc. And each one would need to talk with a couple of others. The problem : to separate and allowing those to be separate deployable, you would have to get rid of cmr's and make the modules talk with each other through session facades. In this case even with cmr read-ahead would do nothing to avoid the n*cmr needed to access each entity. And worse, how could I manage the constraints between 2 related (and module separated) entities? one would need to consult the dependent module (via session facade) to see if it could be deleted... I don't know what going be the solution, throwing entities away, or making up a monolitic system using cmr. any suggestions? is there anyone that modeled a very big system using CMP/CMR?? how to isolate and decouple the sub-systems, isn't it what we've learned from Software Engineering classes? and and we are at a point in the construction and having a defined arquitecture that is almost impossible go back (or at least it would be a lot of waste of time). May applications happily use CMP today, and these applications will benefit from the work that we put into the cmp engine on a daily basis. The applications that don't use CMP can only get benefits from what they can program by them selves. As I said it comes down to a trade off. Also, I truly believe that the Jboss persistence engine will be able to be on par with any custom code using a simple CMP 2 interface, because we will allow you to plug in your optimized code. The best of both worlds. -dain Emerson Cargnin - SICREDI Serviços wrote: i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- | Emerson Cargnin
RE: [JBoss-user] Entity Bean Performance Tuning Help
My life became _blissful_ about a month ago when I ditched entity beans and started using Hibernate for persistence. My data model objects are all pure java beans which I can 1) pass out of the EJB system and 2) cache anywhere I want, for however long I want, in a clustered environment. This seriously cut out 1/3 of my code. I will _never_ use entity beans again. And yes, I was using XDoclet and all the cool tools to make entity beans easier - the very fact that this technology requires so many tools to salve the pain is the surest sign that there is something horribly, horribly wrong... JBoss and Session beans are great - but after two years of working with entity beans on three different appservers, I have come to the conclusion that the problem domain for which they are appropriate is very narrow, if it exists at all. There are a lot of other O/R persistence mechanisms available, and they're almost all much easier to learn and use. Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Luttrell, Peter [mailto:PLuttrell@;starkinvestments.com] > Sent: Tuesday, October 29, 2002 8:39 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > Georg, > > I used 2 other non-ejb solutions to get what I needed done. > > Cache the dataobjects in the webtier. It will only work in certain cases, > 2/3 in my case. I know it's duplicating work that the ejb container > should > do, but if there is noting that can be done to JBoss to get performance > acceptable then... > > Paginate the results. Checkout this taglib, it does it all for you > automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it > better because IE can render the pages very fast, compared to the super > long > time it takes with large tables. > > .peter > > -Original Message- > From: Georg Schmid [mailto:georg-schmid@;ti.com] > Sent: Tuesday, October 29, 2002 2:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > > First of all: > > This was only an experiment to check the impact of the > EntitySynchronizationInterceptor on performance. > Of course this is nothing you should do in a real setup. I know what the > EntitySynchronizationInterceptor is for. > > I have been using JBoss for almost a year, reading almost all posts on > the Jboss dev, user and cvs mailing lists, as well as searching the > forums regulary, if I have an issue to solve. > > My problem is: Creating value objects through calling a method on an > CMP2.0 entity bean takes 3 to 10 times more time than walking through an > equivalent result set of a 'raw' JDBC query. I tried to dig into this > issue by stripping down the interceptor stack !as an experiment! to the > bare minimum. The result of this experiment was, that the > EntitySynchronizationInterceptor is the only interceptor, that changes > performance significantly in my setup. Removing the transaction or > security interceptors did not have any significant impact. > > Getting the data from the database into the Jboss server memory is not > the problem. The finder I am using for testing returns a result set with > 1000 rows. It uses the default load group. This means that all data is > in memory after the finder has completed, which takes only a few hundred > milliseconds, just like issuing a "select * from BeanTable". For this > reason playing around with page sizes and load groups etc. is pointless. > My experience is that locking has no measurable effect on the > performance (the performance test is strictly single-user). > > The time is lost when I walk through the collection of entity beans > returned by the finder and call a method on each to create the value > objects (one method call per value object). Others have come to the same > conclusion, but I have not found a post that points to a solution of > this problem. > > I really would like to be able to do a web page, that displays at most > about 4000 rows, using entity beans and CMP2.0. But with the current > performance I have to switch to direct JDBC calls in my stateless > session beans every time I have to display more than 500 rows (Jboss > 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db > on similar hardware). > > This is the issue I am trying to solve. If you could help me with that > I'd really appreciate it. > Thanks. > > Regards > Georg > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke > Sent: Tuesday, October 29, 2002 07:24 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Georg stop spewing nonsenseNever ever take out the synchronization > interceptor! It registers synchronzations with the TM so that the > entity bean changes get committed! Please read the for-pay docs or > review the archives. I have explained this shit over and over. > > I'v
Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson, I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems. May applications happily use CMP today, and these applications will benefit from the work that we put into the cmp engine on a daily basis. The applications that don't use CMP can only get benefits from what they can program by them selves. As I said it comes down to a trade off. Also, I truly believe that the Jboss persistence engine will be able to be on par with any custom code using a simple CMP 2 interface, because we will allow you to plug in your optimized code. The best of both worlds. -dain Emerson Cargnin - SICREDI Serviços wrote: i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN. Jason Westra wrote: Dain wrote: I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Controlling Number of MDB Instances on a per MDB basis?
Hello! I see in standardjboss.xml some pool settings to help control how many MDBs are instantiated. What is the difference between the container-invoker-conf/MaximumSize (default 15) and the container-pool-conf/MaximumSize (default 100)? Also, is there a way to control this on a per MDB basis? Can I, for instance, have a pool of 100 instances of MDB A, but a pool of 10 instances of MDB B? Thanks very much for your help! I'm using jBoss 3.0.2 on Linux 2.4.18 w/ Sun 1.3.1 VM. thanks, Seth --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Dain wrote: >>I disagree with you here. It depends on the type of reads you are >>doing. A lot of applications increase performance by offloading >>processing to the database with very complex queries and stored >>procedures, and the current CMP design can not benefit from this design. This was my point. Sounds like you agree. :) The current CMP design has problems with large, complex reads. You can't effectivly use CMP for everything, nor was the EJB spec's CMP section able solve ALL data query problems. J -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 29, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help Jason Westra wrote: > Hi JBoss friends, > > I tend to agree with Bill and Dain's last posting here. There are certain > things that CMP is not designed to do *well* and large, heavy reads is one > of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. > I'd venture to guess the same performance problem will occur on other app > servers, in which case, it is not a war of servers, but a principle of > application design (SSB+JDBC vs. CMP). If the numbers come in much better > from testing on other app servers, we need to get JBoss "fixed". Until then, > I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Entity Bean Performance Tuning Help
Jason Westra wrote: Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Re: JBoss3.0, Tomcat, SSL
Yeah, that helped a lot. (duh!) Thanks a lot Jules, -- John Message: 3 Date: Tue, 29 Oct 2002 16:11:49 + From: Jules Gosnell <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] JBoss3.0, Tomcat, SSL Reply-To: [EMAIL PROTECTED] https://localhost:8443/pc ? Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them. I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 10:28 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. My bet is that it is a problem with your code More comments inlined. > I have a method, which does this: > > 1) begin manual transaction with jta > > 2) calls findBySomeCriteria() which returns some 750 ejbs > ->takes 200-300ms (good) > Entities not loaded yet... > 3) then iterate through each, calling one of the methods > i do this to fill the readahead cache for all the beans in an > attempt to isolate the performance problem > ->takes 80-100ms (good) > Entites are loaded by this time. This leads me to believe it is your DataObject creation that is slow. More comments follow... > 4) then iterate through each, and constructing a dataobject that I > use for display purposes > ->takes 2000-2500ms (this seams way too long) > > 5) commit the transaction, blablabla.. > > I used 2 other non-ejb solutions to get what I needed done. > > Cache the dataobjects in the webtier. It will only work in certain cases, > 2/3 in my case. I know it's duplicating work that the ejb > container should > do, Why should the EJB tier be responsible for caching your DataObjects? Unless you explicitly code this in ejbLoad, only persistent fields are stored. > but if there is noting that can be done to JBoss to get performance > acceptable then... > Try another app server then. I'd be curious to see if it is much faster. Bill > Paginate the results. Checkout this taglib, it does it all for you > automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it > better because IE can render the pages very fast, compared to the > super long > time it takes with large tables. > > .peter > > -Original Message- > From: Georg Schmid [mailto:georg-schmid@;ti.com] > Sent: Tuesday, October 29, 2002 2:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > > First of all: > > This was only an experiment to check the impact of the > EntitySynchronizationInterceptor on performance. > Of course this is nothing you should do in a real setup. I know what the > EntitySynchronizationInterceptor is for. > > I have been using JBoss for almost a year, reading almost all posts on > the Jboss dev, user and cvs mailing lists, as well as searching the > forums regulary, if I have an issue to solve. > > My problem is: Creating value objects through calling a method on an > CMP2.0 entity bean takes 3 to 10 times more time than walking through an > equivalent result set of a 'raw' JDBC query. I tried to dig into this > issue by stripping down the interceptor stack !as an experiment! to the > bare minimum. The result of this experiment was, that the > EntitySynchronizationInterceptor is the only interceptor, that changes > performance significantly in my setup. Removing the transaction or > security interceptors did not have any significant impact. > > Getting the data from the database into the Jboss server memory is not > the problem. The finder I am using for testing returns a result set with > 1000 rows. It uses the default load group. This means that all data is > in memory after the finder has completed, which takes only a few hundred > milliseconds, just like issuing a "select * from BeanTable". For this > reason playing around with page sizes and load groups etc. is pointless. > My experience is that locking has no measurable effect on the > performance (the performance test is strictly single-user). > > The time is lost when I walk through the collection of entity beans > returned by the finder and call a method on each to create the value > objects (one method call per value object). Others have come to the same > conclusion, but I have not found a post that points to a solution of > this problem. > > I really would like to be able to do a web page, that displays at most > about 4000 rows, using entity beans and CMP2.0. But with the current > performance I have to s
RE: [JBoss-user] Entity Bean Performance Tuning Help
JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. My bet is that it is a problem with your code More comments inlined. > I have a method, which does this: > > 1) begin manual transaction with jta > > 2) calls findBySomeCriteria() which returns some 750 ejbs > ->takes 200-300ms (good) > Entities not loaded yet... > 3) then iterate through each, calling one of the methods > i do this to fill the readahead cache for all the beans in an > attempt to isolate the performance problem > ->takes 80-100ms (good) > Entites are loaded by this time. This leads me to believe it is your DataObject creation that is slow. More comments follow... > 4) then iterate through each, and constructing a dataobject that I > use for display purposes > ->takes 2000-2500ms (this seams way too long) > > 5) commit the transaction, blablabla.. > > I used 2 other non-ejb solutions to get what I needed done. > > Cache the dataobjects in the webtier. It will only work in certain cases, > 2/3 in my case. I know it's duplicating work that the ejb > container should > do, Why should the EJB tier be responsible for caching your DataObjects? Unless you explicitly code this in ejbLoad, only persistent fields are stored. > but if there is noting that can be done to JBoss to get performance > acceptable then... > Try another app server then. I'd be curious to see if it is much faster. Bill > Paginate the results. Checkout this taglib, it does it all for you > automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it > better because IE can render the pages very fast, compared to the > super long > time it takes with large tables. > > .peter > > -Original Message- > From: Georg Schmid [mailto:georg-schmid@;ti.com] > Sent: Tuesday, October 29, 2002 2:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > > First of all: > > This was only an experiment to check the impact of the > EntitySynchronizationInterceptor on performance. > Of course this is nothing you should do in a real setup. I know what the > EntitySynchronizationInterceptor is for. > > I have been using JBoss for almost a year, reading almost all posts on > the Jboss dev, user and cvs mailing lists, as well as searching the > forums regulary, if I have an issue to solve. > > My problem is: Creating value objects through calling a method on an > CMP2.0 entity bean takes 3 to 10 times more time than walking through an > equivalent result set of a 'raw' JDBC query. I tried to dig into this > issue by stripping down the interceptor stack !as an experiment! to the > bare minimum. The result of this experiment was, that the > EntitySynchronizationInterceptor is the only interceptor, that changes > performance significantly in my setup. Removing the transaction or > security interceptors did not have any significant impact. > > Getting the data from the database into the Jboss server memory is not > the problem. The finder I am using for testing returns a result set with > 1000 rows. It uses the default load group. This means that all data is > in memory after the finder has completed, which takes only a few hundred > milliseconds, just like issuing a "select * from BeanTable". For this > reason playing around with page sizes and load groups etc. is pointless. > My experience is that locking has no measurable effect on the > performance (the performance test is strictly single-user). > > The time is lost when I walk through the collection of entity beans > returned by the finder and call a method on each to create the value > objects (one method call per value object). Others have come to the same > conclusion, but I have not found a post that points to a solution of > this problem. > > I really would like to be able to do a web page, that displays at most > about 4000 rows, using entity beans and CMP2.0. But with the current > performance I have to switch to direct JDBC calls in my stateless > session beans every time I have to display more than 500 rows (Jboss > 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db > on similar hardware). > > This is the issue I am trying to solve. If you could help me with that > I'd really appreciate it. > Thanks. > > Regards > Georg > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke > Sent: Tuesday, October 29, 2002 07:24 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Georg stop spewing nonsenseNever ever take out the synchronization > interceptor! It registers synchronzations with the TM so that the > entity bean changes get
Re: [JBoss-user] Entity Bean Performance Tuning Help
Peter, I honestly wish you the best of luck with your project. There are some application that need performance beyond what CMP can offer. Usually people come to this conclusion way to early, but I bet you spent a long time looking at you specific problem. It really comes down to a trace off, highly skilled programmer time to implement a custom JDBC and caching layer vs. more hardware. In most cases the hardware is cheap but there are cases where programmer is cheaper. If you think this is a JBoss specific performance problem, please post a bug report and I'll try to fix it. -dain Luttrell, Peter wrote: Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid@;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a "select * from BeanTable". For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg Schmid Sent: Monday, October 21, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Peter, I have a similar problem and tried to dig into it. You may have a look at the thread http://www.jboss.org/forums/thread.jsp?forum=46&thread=20827 in the forums. To summarize: the EB caching works perfectly (I guess it is as fast as you can get with JDBC), but getting the r
RE: [JBoss-user] Entity Bean Performance Tuning Help
Peter, it's a great relief to see, that I am not the only one... I have not given up hope yet, but I cannot crank out enough hours to get to the core of the problem. In the app I did before the current one, I used the paging and web layer caching approach you suggest, albeit on a small scale. Then I embraced EJB and CMP2.0. Despite my current problems I am still convinced that it was the right decision. I find it more convenient to put my tables inside a using the overflow:auto css style, so I can simply scroll down the complete list without paging. I am using the JSTL to do the presentation layer. Actually I had JBoss running under OptimizeIt two weeks ago, but then I was distracted and now my evaluation license expired. May be you try to use SwiftMQ (they used to have docs on how to integrate with Jboss on their website). My company did a performance comparison against IBM MQ Series, and SwiftMQ was significantly faster (lean and mean, so to say, but no work flow component etc.). Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Luttrell, Peter Sent: Tuesday, October 29, 2002 17:39 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid@;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a "select * from BeanTable". For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contention
RE: [JBoss-user] Entity Bean Performance Tuning Help
Georg, I used 2 other non-ejb solutions to get what I needed done. Cache the dataobjects in the webtier. It will only work in certain cases, 2/3 in my case. I know it's duplicating work that the ejb container should do, but if there is noting that can be done to JBoss to get performance acceptable then... Paginate the results. Checkout this taglib, it does it all for you automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it better because IE can render the pages very fast, compared to the super long time it takes with large tables. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid@;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a "select * from BeanTable". For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg > Schmid > Sent: Monday, October 21, 2002 4:32 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Peter, > > I have a similar problem and tried to dig into it. > You may have a look at the thread > http://www.jboss.org/forums/thread.jsp?forum=46&thread=20827 in the > forums. > > To summarize: the EB caching works perfectly (I guess it is as fast as > you can get with JDBC), but getting the rows in memory into a data or > value object is slow. Creating n value objects for n EB instances > involves going through the interceptor stack n times, and this is, > where the time is lost. > > I incrementally stripped down the interceptor stack using a custom > configuration in my jboss.xml, but without much success. > > The only way to really speed up things that I found was removing the > synchronization interceptor, which improves performance by a factor of > 2, if no or only one attribute is read, but makes it worse, if many > attributes have to be read. > > BTW: I used commi
Re: [JBoss-user] JBoss3.0, Tomcat, SSL
https://localhost:8443/pc ? Jules [EMAIL PROTECTED] wrote: I'm new to JBoss and SSL. Using jboss-3.0.3_tomcat- 4.0.5, I have created a test application packaged as "pc.ear". I want to use SSL to protect connections between a client's browser and the servlets/JSP pages of the application. I followed the advice and examples given here: http://www.jboss.org/forums/thread.jsp? forum=49&thread=22110&message=3750442&q=%2BJBOSS+% 2BTOMCAT+%2BSSL+%2BPROBLEMS+#3750442 Following that advice, I believe I have been able to get SSL working on port 8443 by creating a keystore (server.keystore) with a "tomcat" alias, and adding the following to my tomcat4-services.xml file: minProcessors = "5" maxProcessors = "75" acceptCount = "10" debug = "0"/> However, when I go to http://localhost:8443/pc, all I see is "" (i.e., some encrypted stuff). I'm sure I'm missing something very fundamental here, but I don't know what -- I'm a first-timer. Can anyone tell me what I have to do to actually get html/JSP/servlet output to display in the browser via the SSL port (8443)? Thanks a lot for any help, -- John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] JBoss3.0, Tomcat, SSL
As a follow-up to my prior e-mail (same subject), I note that the JBoss.3.0QuickStart.Draft3.pdf refers to configuring a jboss.jcml configuration file, but I don't see such a file anywhere in the JBoss installation. Do I need to create this file? Where should I put it? Thanks for any help. -- John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Re: transactions in stateless session bean.
Hi, Justin, I'm seeing something almost identical in a unit test I have. My code is slightly different than yours, but not by much. Basically, I create add an object to another (parent) object and when I try to fetch it by primary key and then ask for the child collection I get the same error. FYI, my entity beans are all local and I'm testing via Cactus, so it's a slightly different configuration. At any rate, hopefully somebody will reply with some further information. I have researched it and am a dead-end. Regards, Rob --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
JBoss is losing credibility in our firm due to this performance problem as well as the issues i've noted about JMS performance. If anyone cares whether JBoss is actually used in the production environment, the team might consider investing time in making it perform well. .peter -Original Message- From: Georg Schmid [mailto:georg-schmid@;ti.com] Sent: Tuesday, October 29, 2002 2:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a "select * from BeanTable". For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg > Schmid > Sent: Monday, October 21, 2002 4:32 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Peter, > > I have a similar problem and tried to dig into it. > You may have a look at the thread > http://www.jboss.org/forums/thread.jsp?forum=46&thread=20827 in the > forums. > > To summarize: the EB caching works perfectly (I guess it is as fast as > you can get with JDBC), but getting the rows in memory into a data or > value object is slow. Creating n value objects for n EB instances > involves going through the interceptor stack n times, and this is, > where the time is lost. > > I incrementally stripped down the interceptor stack using a custom > configuration in my jboss.xml, but without much success. > > The only way to really speed up things that I found was removing the > synchronization interceptor, which improves performance by a factor of > 2, if no or only one attribute is read, but makes it worse, if many > attributes have to be read. > > BTW: I used commit option B, read-ahead on-load, and the Instance Per > Transaction setup in my experiments. > > The pattern you found is interesting. Because there are so many things > impacting the performance, it is hard to tell, whom to ask (Dain, > Bill, David,...). > > Bill Burke did some perform
[JBoss-user] JBoss3.0, Tomcat, SSL
I'm new to JBoss and SSL. Using jboss-3.0.3_tomcat- 4.0.5, I have created a test application packaged as "pc.ear". I want to use SSL to protect connections between a client's browser and the servlets/JSP pages of the application. I followed the advice and examples given here: http://www.jboss.org/forums/thread.jsp? forum=49&thread=22110&message=3750442&q=%2BJBOSS+% 2BTOMCAT+%2BSSL+%2BPROBLEMS+#3750442 Following that advice, I believe I have been able to get SSL working on port 8443 by creating a keystore (server.keystore) with a "tomcat" alias, and adding the following to my tomcat4-services.xml file: However, when I go to http://localhost:8443/pc, all I see is "" (i.e., some encrypted stuff). I'm sure I'm missing something very fundamental here, but I don't know what -- I'm a first-timer. Can anyone tell me what I have to do to actually get html/JSP/servlet output to display in the browser via the SSL port (8443)? Thanks a lot for any help, -- John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Concurrency problem
Arijit Ghosh wrote: > Any pointers for concurrency related issues ? The J2EE specifications contain lots of information about concurrency-related issues. Perhaps you have a more specific question? Benjamin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] binding ejb to wrong datasource
thanks for the help. i'm using xdoclet, and i only had to change the @jboss:res-ref to @jboss:resource-manager. simple as can be! -Original Message- From: Guy Rouillier [mailto:guy-rouillier@;speakeasy.net] Sent: Monday, October 28, 2002 9:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] binding ejb to wrong datasource Why do you have a resource-ref section in jboss.xml? This section should be resource-manager. Here is a working section from one of my EJBs. java:/ordermanagementDB jdbc/ordermanagementDB - Original Message - From: "Sonnek, Ryan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 10:57 AM Subject: [JBoss-user] binding ejb to wrong datasource > does anyone know why my ejb resources are always trying to bind to > java:/DefaultDS?? in jboss 3.0.3 when i deploy my ejb's, they always try to > bind to DefaultDS instead of the datasource i have configured for them. i > have 3 datasources configured, DefaultDS, was1DS, and was2DS to oracle > databases. here are the important parts of my ejb-jar.xml and my jboss.xml. > i don't see why it won't work with my other datasources. > > ejb-jar.xml > > > DutyManager > > DutyManager > > com.bpc.bcs.interfaces.DutyManagerHome > com.bpc.bcs.interfaces.DutyManager > com.bpc.bcs.ejb.DutyManagerSession > Stateless > Container > > > jdbc/bcs/bcsuser > javax.sql.DataSource > Container > > > > > jboss.xml > > DutyManager > ejb/bcs/dutyManager > > jdbc/bcs/bcsuser > java:/was2DS > > > > here's the message from jboss when the ejb is deployed: > 09:48:52,424 DEBUG [StatelessSessionContainer] Begin java:comp/env for EJB: > DutyManager > 09:48:52,424 DEBUG [StatelessSessionContainer] TCL: > java.net.URLClassLoader@230be4 > 09:48:52,424 DEBUG [StatelessSessionContainer] Binding resource manager: > java:/DefaultDS to JDNI ENC as: jdbc/bcs/bcsuser > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] javax.naming.NameAlreadyBoundException if I start my JBoss 2.4.4
Hi,
If I start my JBoss 2.4.4 i get
javax.naming.NameAlreadyBoundException; remaining name 'env'
at org.jnp.server.NamingServer.createSubcontext(NamingServer.java:451)
at
org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:648)
at
org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:634)
at org.jboss.ejb.Container.setupEnvironment(Container.java:447)
if JBoss deploys my ejb's. The crazy thing is the same ejb's get deployed on
another machine.
I have debugged a litle and found out that it happens in setupEnvironment
method of the JBoss Container class. The first time it comes into that
method every thing is fine, but the second time if he calls
Context ctx = (Context) new InitialContext().lookup("java:comp");
Context envCtx = ctx.createSubcontext("env"); <
I get that exception
Does someone have any suggestions?
Many thanks !
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] installing JDBCand connection to ORACLE with JBOSS
First of all, I think you have to rename classes12.zip to classes12.jar. In oracle-service.xml add a tag like this: OracleDS jdbc:oracle:thin:@IPADDRESS:1521:ORCL oracle.jdbc.driver.OracleDriver USERNAME PASSWORD -Original Message- From: Pankaj Jain [mailto:pankaj.jain@;seepz.tcs.co.in] Sent: Tuesday, October 29, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] installing JDBCand connection to ORACLE with JBOSS hi I have downloaded the jdbc driver(clssess12.zip) and putted into the default/lib directory. Now for connecting to database what next step i have to do. I have dowloaded oracle-service.xml file but i did n't have any guide to edit it. I am using jboss-3.0.3_tomcat-4.1.12. And I am not getting any proper guide to connect to the databse. pls let me know your response. Regards, Pankaj Kumar Jain Tata Consultancy Services Phone:00-91-22-8291680 Ext:1150 Dial Com:1108 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] installing JDBCand connection to ORACLE with JBOSS
hi I have downloaded the jdbc driver(clssess12.zip) and putted into the default/lib directory. Now for connecting to database what next step i have to do. I have dowloaded oracle-service.xml file but i did n't have any guide to edit it. I am using jboss-3.0.3_tomcat-4.1.12. And I am not getting any proper guide to connect to the databse. pls let me know your response. Regards, Pankaj Kumar Jain Tata Consultancy Services Phone:00-91-22-8291680 Ext:1150 Dial Com:1108 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Concurrency problem
Hi, Any pointers for concurrency related issues ? I am using Jboss3.0 with TOmcat 4.0.3 with Stateless Session Beans and Castor as the persistence layer. Regards, Arijit --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] A question on Jboss scalability!
Bill Burke wrote: I did ran ECPerf tests and the RICE study on both linux and win2k. Linux was 2 times slower than Win2k. Not sure why, not much of a sys-admin so wouldn't know what to tune. When did you try this? What versions of jboss and Java VMs on both win2k and linux? I have no problem accepting this if you used 1.3.x from sun on both platform, as it is very slow on linux. If this is true, can you do the tests again using better JVMs under linux? IBM/blackdown/jrockit 1.3 on linux is much faster. 1.4 is also much faster than sun 1.3. Some other performance tidbits: - JBossWeb (Jetty) is 30% faster than Tomcat 4.0.4 under the heavy load tests I did. (RICE study). - Make sure that your Web tier and EJB tier are running in the same VM. You'll see huge performance gains. - Make sure you have enough DB connections in your DB pool. Otherwise your system will start to slow down under heavy load. - Are you having problems with Entity Bean locking? JBoss 3.0.4 (Branch_3_0) has a EntityBean monitoring MBean. In jboss-service.xml in .../server/default/conf (or server/all/conf) uncomment out the EntityBeanMonitor MBean. Run your stress test again, and then go to the JMX console :8080/jmx-console and view the stats on your Entity bean concurrency issues. If you have high concurrency and high wait times then there is a locking problem. Consult the for-pay documentation on how to solve Entity Bean locking problems - Are you sure you're not overloading your DB's I/O? - Hire JBossGroup to help out your performance. I personally have helped out Dow Jones Indexes (www.djindexes.com) to improve their performance to over 1000% as well as Elogex (www.elogex.com). Other JBossGroup consultants have done the same at other sites if you need references. - From my ECPerf tests I've found that the DB was the limiting factor. But DB could be limiting because of jboss use it ineffective. Bill Burke JBossGroup -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Rahul Ganjoo Sent: Monday, October 28, 2002 8:11 AM To: [EMAIL PROTECTED] Subject: [JBoss-user] A question on Jboss scalability! Hi All! I have a few queries regarding application performance and scalability of a web based app. Jboss: 3.x Tomcat:4.0.4 Op Sys: Linux(red hat 7.2),win2k,solaris DB:Oracle 9i H/W:Pentium 4 dual ,1GB RAM. Now using a profiling/testing tool we saw that not more than 440 users could use the system concurrently(on win 2000 enterprise server).The app typically has the following archtitecture: UI Layer: Jsps Middleware: Session beans DB layer: Entity beans with CMP2.0 or in some cases DAO layer(JDBC calls from session beans) I don't know if this info is vague or enough to tell me 1.What Jboss specific things should I take care of in order to scale up to 1000+ concurrent users. 2.Any other tips that will enable me to scale up. 3.typically how does the performance vary from win2k to linux to solaris. 4.Is there any upper limit on the number of users that Jboss can support concurrently. We are not running Jboss clusters yet. Guys let me know if you need any other info to help me with this. Thanks a lot in advance, Regards, Rahul Ganjoo. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Entity Bean Performance Tuning Help
Hello Georg, Do you mean that your slowness problem occurs when accessing the collection *even* in mono-threaded behaviour? If I understand your scenario, you have something like this: - a web page that display the content of 4000 entity beans (either directly or using a SLSB) - the entity beans are loaded at once (no N+1 issue wrt data loading) - everything occurs in a single transaction - you hit the refresh page of your browser (i.e. only 1 access on the whole system) - you get really bad data at the synchronisation level. Right? As what you describes seems to be an experiment, do you have a very small example (EAR) that contains: - the CMP that you use - a servlet/JSP that uses direct JDBC call to retrieve this data (with a time counter) - a servlet/JSP that uses the CMP to retrieve the data (with a time counter) - this would be using the embedded HSQL DB - a servlet/JSP that can be used to populate the DB with dummy values Maybe, if we are lucky, you already have this small setup ready: would you agree to send it? cheers, Sacha > My problem is: Creating value objects through calling a method on an > CMP2.0 entity bean takes 3 to 10 times more time than walking through an > equivalent result set of a 'raw' JDBC query. I tried to dig into this > issue by stripping down the interceptor stack !as an experiment! to the > bare minimum. The result of this experiment was, that the > EntitySynchronizationInterceptor is the only interceptor, that changes > performance significantly in my setup. Removing the transaction or > security interceptors did not have any significant impact. > > Getting the data from the database into the Jboss server memory is not > the problem. The finder I am using for testing returns a result set with > 1000 rows. It uses the default load group. This means that all data is > in memory after the finder has completed, which takes only a few hundred > milliseconds, just like issuing a "select * from BeanTable". For this > reason playing around with page sizes and load groups etc. is pointless. > My experience is that locking has no measurable effect on the > performance (the performance test is strictly single-user). > > The time is lost when I walk through the collection of entity beans > returned by the finder and call a method on each to create the value > objects (one method call per value object). Others have come to the same > conclusion, but I have not found a post that points to a solution of > this problem. > > I really would like to be able to do a web page, that displays at most > about 4000 rows, using entity beans and CMP2.0. But with the current > performance I have to switch to direct JDBC calls in my stateless > session beans every time I have to display more than 500 rows (Jboss > 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db > on similar hardware). --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Erroneous deadlock detected???
The behaviour imposed by the pessimistic locking violates the principle
of "least surprise" for most Jboss users, I guess. That's the reason why
you have to answer these questions a million times.
If I am using all the EJB/J2EE/CMP stuff, I expect that I do not have to
care about concurrency, transactions and so on. That's the application
server's business.
So when I get deadlock exceptions the first time two users hit the same
web page concurrently, both accessing the same (bad luck!) entity beans
read-only, I am taken aback. Especially if I'm doing only basic stuff
and nothing fancy.
Regards
Georg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke
Sent: Tuesday, October 29, 2002 07:16
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Erroneous deadlock detected???
Queued pessmistic is useful for caching. Without it you can't cache.
You're wrong that it turns jBoss into single tasking. It really depends
on your application and there are other settings you can use. Buy the
for-pay docs(or search the archives, I've answered these questions a
million times before). It goes into details about locking policies.
Ok, so why did he get deadlock detected?
begin tx1
- create entity > this locks it into tx1
- entity.setX ---> tx1 suspended tx2 starts, deadlock, tx1 has lock.
Besides, you can't do a requiresnew call anyways because the newly
created entity will never have been committed! Learn what transaction
isolation is.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg
> Schmid
> Sent: Friday, October 25, 2002 6:14 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] Erroneous deadlock detected???
>
>
>
> I ran into this same problem a while ago, and I suggested the same (at
> least the thread, that holds the lock, should not be locked out).
> Somebody wrote a 'SimpleReadWriteEJBLock' class, that seems to achieve
> exactly this, but I could not find any info related to it.
>
> You can also try to play around with the method attribute read-only
> setting in jboss.xml (see the DTD). To get better concurrency you may
> consider switching to the Instance Per Transaction configuration (see
> standardjboss.xml) .
>
> The QueuedPessimisticEJBLock does not make any sense with CMP, IMHO
> (if you use it, it turns JBoss into a single tasking system).
>
>
> Georg
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Jim
> Crossley
> Sent: Thursday, October 24, 2002 22:06
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] Erroneous deadlock detected???
>
>
> Well, it would seem to me that a ThreadLocal instance could help solve
> this problem. If one thread tries to acquire a lock it already owns,
> it ought to get it, right?
>
> If we were to apply the same semantics you describe to a simple Java
> class, then calling setX would always block...
>
> class C
> {
> synchronized void setX() {
> setY();
> }
> synchronized void setY() {
> ;
> }
> }
>
> If this is really the way JBoss works, and nobody knows a good reason
> why it should, can someone point me to the package/class responsible
> for this behavior and I'll take a whack at fixing it?
>
> Thanks,
> Jim
>
> On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> > Explanation attempt inline.
> >
> > Regards,
> > Michael Bartmann
> >
> > Jim Crossley wrote:
> > > I have an MDB with the following pseudocode in its onMessage
> > > method:
> > >
> > > public void onMessage(Message msg)
> > > {
> > > // Entity bean = home.create(...)
> > > // bean.setX(...)
> > this starts a tx1 and locks the instance bean.
> > > // bean.setY(...)
> > this suspends the tx1 on bean temporarily,
> > and starts a tx2, which tries to obtain the lock on the bean, which
> > it
>
> > will never get, because tx1 is not commited or rollbacked yet. We
> > had this problem under 2.4.4 w/o deadlock detection. Problem: even
> > the tx timeout didn't work in this case; the server locked
> forever... :-(
> > > }
> > >
> > > Each of the three methods, create, setX, and setY have a
> > > trans-attribute of "RequiresNew". With only one client posting a
> > > message, a "deadlock detected" exception is thrown when setX is
> > > invoked. How can deadlock occur when only one thread is active
> > >
> > > Thanks,
> > > Jim
> > >
> > >
> > >
> > >
> > > ---
> > > This sf.net email is sponsored by: Influence the future of
> > > Java(TM) technology. Join the Java Community
> > > Process(SM) (JCP(SM)) program now.
> > >
> http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/jav
> av
> ote
> > > ___
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-user
> > >
> >
RE: [JBoss-user] Entity Bean Performance Tuning Help
First of all: This was only an experiment to check the impact of the EntitySynchronizationInterceptor on performance. Of course this is nothing you should do in a real setup. I know what the EntitySynchronizationInterceptor is for. I have been using JBoss for almost a year, reading almost all posts on the Jboss dev, user and cvs mailing lists, as well as searching the forums regulary, if I have an issue to solve. My problem is: Creating value objects through calling a method on an CMP2.0 entity bean takes 3 to 10 times more time than walking through an equivalent result set of a 'raw' JDBC query. I tried to dig into this issue by stripping down the interceptor stack !as an experiment! to the bare minimum. The result of this experiment was, that the EntitySynchronizationInterceptor is the only interceptor, that changes performance significantly in my setup. Removing the transaction or security interceptors did not have any significant impact. Getting the data from the database into the Jboss server memory is not the problem. The finder I am using for testing returns a result set with 1000 rows. It uses the default load group. This means that all data is in memory after the finder has completed, which takes only a few hundred milliseconds, just like issuing a "select * from BeanTable". For this reason playing around with page sizes and load groups etc. is pointless. My experience is that locking has no measurable effect on the performance (the performance test is strictly single-user). The time is lost when I walk through the collection of entity beans returned by the finder and call a method on each to create the value objects (one method call per value object). Others have come to the same conclusion, but I have not found a post that points to a solution of this problem. I really would like to be able to do a web page, that displays at most about 4000 rows, using entity beans and CMP2.0. But with the current performance I have to switch to direct JDBC calls in my stateless session beans every time I have to display more than 500 rows (Jboss 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db on similar hardware). This is the issue I am trying to solve. If you could help me with that I'd really appreciate it. Thanks. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 07:24 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help Georg stop spewing nonsenseNever ever take out the synchronization interceptor! It registers synchronzations with the TM so that the entity bean changes get committed! Please read the for-pay docs or review the archives. I have explained this shit over and over. I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in jboss-service.xml to uncomment it. Gives you # contentions in table with bean beans. Also gives averages and other stats. I'll be adding this to docs eventually. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg > Schmid > Sent: Monday, October 21, 2002 4:32 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Peter, > > I have a similar problem and tried to dig into it. > You may have a look at the thread > http://www.jboss.org/forums/thread.jsp?forum=46&thread=20827 in the > forums. > > To summarize: the EB caching works perfectly (I guess it is as fast as > you can get with JDBC), but getting the rows in memory into a data or > value object is slow. Creating n value objects for n EB instances > involves going through the interceptor stack n times, and this is, > where the time is lost. > > I incrementally stripped down the interceptor stack using a custom > configuration in my jboss.xml, but without much success. > > The only way to really speed up things that I found was removing the > synchronization interceptor, which improves performance by a factor of > 2, if no or only one attribute is read, but makes it worse, if many > attributes have to be read. > > BTW: I used commit option B, read-ahead on-load, and the Instance Per > Transaction setup in my experiments. > > The pattern you found is interesting. Because there are so many things > impacting the performance, it is hard to tell, whom to ask (Dain, > Bill, David,...). > > Bill Burke did some performance tests using ECPerf. Maybe he can > report a bit on the results. > > Regards > Georg > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Luttrell, > Peter > Sent: Saturday, October 19, 2002 02:17 > To: '[EMAIL PROTECTED]' > Subject: [JBoss-user] Entity Bean Performance Tuning Help > > > I have something that is taking longer then I would like and am trying > to tune jboss to reduce the time it takes. > >
