We believed JBoss strong marketing but lack of success for
Hello !
We started to port a big enough application from commercial app server to JBoss. We was very excited about new JBoss 3.0 release. We forced many problems but after 2 months we have still one problem and our deadline is not so far. Our problem seats in JBoss implemetation that we discovered an described to Mr Dain Sundstrom. We are not able to get into JBoss source code to mend it.
The question is: Has anybody fired big enough EJB 2.0 application on JBoss 3.0 ?
sincerely Olek
PS. I enclode our correspondention:
>
> We don't use microtransacion.We are aware performance problem without
> transaction block.
> We investigate the problem and this is what we found :
>
> We have the follwoing relations (see number of entieties)
> (50 000 entites) Doc - DocType (6) -one typeDoc have many doc
> (300 000) Role - User (250) -one user have many
> roles
> and now what happens with the follwing code :
>
> tx.begin()
> User user = userHome.findByPrimaryKey(userId); //on-load cache finds many
> users
> DocType type = typeHome.findByPrimaryKey(typdokId); //on-load cache finds
> all 4 doctypes
> //now call roleHome.create so ejbCreate is called
> RoleBean.ejbCreate(user,typDoc,docId){
> setId(counter) //etc
> }
> RoleBean.ejbPostCreate(user,typDoc,docId){
> setUser(user); //!!!!!!!!!!! now JBoss materialize relation
User-Role.
> WHY ?????. It finds all roles for users loaded in cache.
> //becouse there is about 2000 roles for each user and there is 250 users
in
> cache then it materilizes almost whole 300 000 roles. It must take very
long
> time.
> //is there any way to avoid it.
> setDoc(docHome.findByPrimaryKey(docId)); //similary JBoss materializes
all
> docs for DocType which are already in cache. In this case all docs.
> }
> tx.commit();
>
> it seems that problem arise becouse relations between number of entities
> between two sides of relation and becouse JBoss wants to load to much data
> from relation. But why this relation is loaded. I don't want to be. I
never
> call user.getRoles() (I know it could take long time) so I want to no
> materilize relation. In fact setDoc(0 or setUser() in postcreate should
> simply set foreing
> key id.
> I have read Optimized Loading in Your book but I cant find nothing about
> this behaviour. I'm not sure if I could avoid this behaviour with some
lazy
> loading settings. We tried to turn of read-ahead for this relation
> none nothing helps
> Maybe unidirectional realtion would not load this data (i dont know), but
we
> can't use unidirectaional relations becouse both sides are used in
> queries
>
>
>
>
> ----- Original Message -----
> From: "Dain Sundstrom" <dain@daingroup.com>
> To: "Marek Mosiewicz" <marek.mosiewicz@talex.com.pl>
> Sent: Wednesday, July 03, 2002 10:14 PM
> Subject: Re: Could we help in read a-head implementation ?
>
>
> > I don't know of any current issues. I would love any help you can give
> > on this code. I have not stress tested this code, only unit tested for
> > correctness, so any performance analyses would be greatly appreciated.
> >
> > Have you read the Optimized Loading chapter of my documentation? If the
> > loading system is misconfigured, you can get very bad performance
> > O(n^2). The is caused by using readahead with micro transactions (tx
> > for each method invocation), which causes the system to load a lot of
> > extra data and then immediately throw it out when the tx ends.
> >
> > -dain
> >
> > Marek Mosiewicz wrote:
> > > Hello Dain.
> > >
> > > We port some serious EJB 2.0 application from WebLogic to JBoss 3.0.
We
> > > met bug [ 569077 ] read-ahead issues in JBoss 3.0.0
> > > It is little better in JBoss 3.0.1 RC1 but it still can hang for few
> > > minutes in easy operations(our PK is Integer so hashkey is
> > > implemented).Are there still any problems with read achead which You
are
> > > aware ? Could We help in any way ? We could analyze perofrmance, play
> > > with diferent variants or something similar.
> > >
> > > Thanks for Your great work on JBoss :-) It's really good piece of code
> :-)
> > >
> > >
> > > Marek Mosiewicz
