> On Friday 23 November 2001 16:03, you wrote: > > > > So basically you want dynamic EJB-QL. This id possible, > but would be slow. > > The current EJB-QL engine was not designed to be fast, as > all parsing is > > done at start-up. Eventually, I plan on rewriting. > > How slow do you think it would be? Do you think a simple > query would take in > the order of seconds to compile? If that's the case it would > be slow. If it > would take 1/10 s or less than it is acceptable...
I don't know. I think it depends on the complexity of the query, but I would be surprised if it took longer then a 1/10 sec. > > > > To solve this type of problem, I plan on supporting > dynamic-sql. Which > > would allow you to do this type of thing, but would require > you to know the > > database mapping. > > > > What about using finder methods like in BMP EBs? The > responsibility of a BMP > finder method is to return a Collection of primary keys. > That's easy to do > with JDBC/SQL. There would only have to be a way to apply BMP > finders to CMP > beans and we'll have dynamic SQL already. JBossCMP supports custom ejbFind methods just like JAWS did. > Currently I'm using JDBC/SQL to retrieve primary keys and > then a loop of > findByPrimaryKey() for each key to obtain Local interfaces > and it takes about > 1-2 seconds per 30 objects. The abovementioned BMP finders > would speed things > up considerably since it would only take one invocation... I don't under stand what you are doing, but try the ejbFind method. > OK, now something I've already been talking about in a > message two weeks ago > and is still bothering me, since I still don't know for sure what is > happening. It takes 1/2 sec to read the attributes of an EB > instance the > first time called. The second and subsequent requests are > much faster and > happen with lightning speed. You said that it takes ~ 1s to > access 20 beans > on your 1.4 athlon. Well it takes 5 seconds for 10 beans on > my 933MHz Pentium > III with 512MB RAM. I don't believe your machine is 10 times faster. I remember. > You answered the following: > > "I was curious also, so I re-ran my test. The second run always takes > slightly less time ~1-2 sec. The only thing I can think of that is > different in the first execution is the bytecode generator. > On my machine, > a 1.4 athalon, it doesn't take anywhere 1/2 second per bean. I really > haven't been focusing on this type of optimization, but I can > easily add a > line to the init or start method that creates an instance of > the bean. Then > it will only happen during setup. I look at it after the > example code done > (later today)." That sounds like something I would say. > I'm puzzled now. From the experiences that I have and if we > assume that it is > the bytecode generation that is causing this overhead, it > seems that the > bytecode generation is happening for every new instance of > the bean that is > created and then put into the pool. Isn't it true that this > bytecode (the > class) is the same for every instance of the same Entity > Bean? There are as > many different bytecodes (classes) as there are different > Entity Beans. > Maybee I haven't been precise enough: the overhead of 1/2 s > happens every > time I access cmp fields of a bean for the first time for the > particular > entity context (instance of the entity) not for particular > Entity Bean. Bytecode generation happens once per entity type. Are you getting lots "Load Field" debug messages? If you are you need to configure the eager/lazy load groups. If not, then there is something else going on. > So the question is: Is bytecode generation being done for > every new instance > that is put into the pool or just once per Bean? Once per bean. > The lazy generation of the > bytecode is not bothering me if it's done just once per Bean > class. If this > is already the case then my overhead is caused by something > else and not by > bytecode generation... Check the debug logs for excessive queries, and the tx boundaries > I really want to track this down. Could you lend me your test > so I can see > what happens on my machine? > I suppose. -dain _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
