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... > > 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. 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... 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. 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)." 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. So the question is: Is bytecode generation being done for every new instance that is put into the pool or just 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... I really want to track this down. Could you lend me your test so I can see what happens on my machine? Regards, Peter _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
