Re: [JBoss-dev] Re: JBoss/CMP Improvements
tisdagen den 26 november 2002 kl 15.49 skrev Stefan Arentz: I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? Never heard of it... have you used it It doesn't exist, except in my mind. I can start working on it. I've been looking for something ilke that to profile my own J2EE apps ... http://www.yoda.arachsys.com/java/jbench/docs/index.html --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Tuesday, Nov 26, 2002, at 03:40 Europe/Amsterdam, Dain Sundstrom wrote: On Monday, November 25, 2002, at 08:08 PM, Stefan Arentz wrote: I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? Never heard of it... have you used it It doesn't exist, except in my mind. I can start working on it. I've been looking for something ilke that to profile my own J2EE apps ... S. --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
tisdagen den 26 november 2002 kl 03.08 skrev Stefan Arentz: I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? Together with some kind of versioning one could then deploy/bench cascades to a running jboss instance with different versions of the code to test/bench. Not fully sure how to do that tho ... ? ... /peter_f --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Monday, November 25, 2002, at 08:08 PM, Stefan Arentz wrote: I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? Never heard of it... have you used it What kind of access do we have to a Collection? iterator() - should only call the original SELECT query and then fetch a result when Iterator.next() is called or DELETE when remove() is used. add() - should only do a optional SELECT On the PK to prevent duplicates and then INSERT remove() - should only do a SELECT on the PK to find out if the object was part of the collection and then DELETE No... add and remove should (are?) delayed until the context completes (invocation or transaction). They should be preformed as a batch, but that is another story. Is that what the spec says or just good design? All this CMR stuff is really complicated :-) I'm now looking at the code of plugins/cmp/jdbc/bridge/RelationSet.java, which seems like a good starting point for these kinds of optimizations. Spec doesn't say much about synchronization other then everything must be synchronized at the end of tx. The code is very complex, which means it is poorly written. -dain --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Saturday, Nov 23, 2002, at 19:55 Europe/Amsterdam, Dain wrote: On Saturday, November 23, 2002, at 12:20 PM, Stefan Arentz wrote: Dain, what you need is more real use-cases. This is really basic stuff which is used in most applications today. I'll be happy to provide you with more examples of such code that is now performing less optimal in JBoss. I might sound a bit negative but in reality I am *very* positive about JBoss, I just start knowing the code better and start seeing its limitations and strengths. I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? So, here is my first take at the collection problem. What is needed is something that Hibernate calls Lazy Loading or Lazy Initialization. This means that a call like getUsers() returns a smart collection that knows about the (SQL) query that backs it. I think almost *all* database access can be delayed, maybe even the initial select. Except when it is a SELECT FOR UPDATE statement i guess, I'm not sure about that. Should be fairly easy. The collection is already a "smart" object. Looking into this ... What kind of access do we have to a Collection? iterator() - should only call the original SELECT query and then fetch a result when Iterator.next() is called or DELETE when remove() is used. add() - should only do a optional SELECT On the PK to prevent duplicates and then INSERT remove() - should only do a SELECT on the PK to find out if the object was part of the collection and then DELETE No... add and remove should (are?) delayed until the context completes (invocation or transaction). They should be preformed as a batch, but that is another story. Is that what the spec says or just good design? All this CMR stuff is really complicated :-) I'm now looking at the code of plugins/cmp/jdbc/bridge/RelationSet.java, which seems like a good starting point for these kinds of optimizations. S. --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Saturday, November 23, 2002, at 12:20 PM, Stefan Arentz wrote: Dain, what you need is more real use-cases. This is really basic stuff which is used in most applications today. I'll be happy to provide you with more examples of such code that is now performing less optimal in JBoss. I might sound a bit negative but in reality I am *very* positive about JBoss, I just start knowing the code better and start seeing its limitations and strengths. I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. What I will do is write feature requests about specific CMP issues like this one. Good examples with detailed descriptions and code examples. That should help for your 4.0 design and maybe some of those improvements can be implemented for 3.x. I think 3.0 and 3.2 are really important because to be honest I don't see 4.0 available for probably at least another year. This is not bad, it is just the way it works. JBoss went through the same release cycle with 2.4 -> 3.0. Agreed So, here is my first take at the collection problem. What is needed is something that Hibernate calls Lazy Loading or Lazy Initialization. This means that a call like getUsers() returns a smart collection that knows about the (SQL) query that backs it. I think almost *all* database access can be delayed, maybe even the initial select. Except when it is a SELECT FOR UPDATE statement i guess, I'm not sure about that. Should be fairly easy. The collection is already a "smart" object. What kind of access do we have to a Collection? iterator() - should only call the original SELECT query and then fetch a result when Iterator.next() is called or DELETE when remove() is used. add() - should only do a optional SELECT On the PK to prevent duplicates and then INSERT remove() - should only do a SELECT on the PK to find out if the object was part of the collection and then DELETE No... add and remove should (are?) delayed until the context completes (invocation or transaction). They should be preformed as a batch, but that is another story. I don't know the EJB spec really that well, so I'm not sure what kind of problems this would introduce in combination with caching and transactions. There are a couple of problems with this approach though. First of all, the Collection classes don't throw exceptions. So for example, when Collection.iterator() is called, it is impossible to throw a database exception. I'm not sure how to solve this. Maybe the iterator can return a stub null bean that throws an EJBException when accessed, dunno. Sounds flakey though :-) We throw an EJBException when iterator() is called. 'Smart Collections' are easy from a Local Bean when everything is in the same VM. What happens when the bean is remote? Fallback to standard Collections or use a proxy object to access the smart collection? How is that done now? CMR collections are not allowed (by the spec) not be exposed over a remote interface so it's not a problem. I'll be happy to discuss this in more detail or even start hacking on an implementation for 3.x. Great. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBoss/CMP Improvements
Dain,
I'm throwing this on the mailing list because I think it is a an
interesting subject to discuss there. And there are also more people on
the list with similar issues. Hope you don't mind :-)
On Tuesday, November 19, 2002, at 05:37 AM, Dain wrote:
On Monday, November 18, 2002, at 04:21 PM, Stefan Arentz wrote:
On Monday, Nov 18, 2002, at 18:23 Europe/Amsterdam, Dain wrote:
This has already been solved in 3.2 and 4.0. I think that the patch
has been applied to 3.0.4, but I'm not sure, as someone else did the
back port. If you are seeing this behavior in 3.0.4 try Branch_3_0.
If you are still seeing it in Branch_3_0, send me another email.
Dain, thanks for the reply. I just checked out 3.2 and looked at the
queries that it does. I think the problem is still there, but maybe
we are talking about different issues.
Here are some more details. My setup is this:
Users <-> UserGroups <-> Groups
This is a Many to Many relation, JBoss generates the UserGroups table
which has a UserId and GroupId.
I am doing this to add a user to a group:
void Group.addUser(User user)
{
Collection users = this.getUsers();
if (users.contains(user) == false) {
users.add(user);
}
}
It generates the following query:
select UserId from USERGROUPS where GroupId = ?
My idea was to delay the actual loading of this data until
users.iterator() or users.size() is being called ... for simple
add/delete operations it is not needed at all i think.
Now I understand. I don't think the optimization I added would help
here. The (bad) idea was a user would never call getUsers unless
they really wanted to access the data, but now I see that this is
plain wrong. I think this will require a big architectural change, so
I personally would leave it for 4.0. If you want to take a look at
it, be careful with the transaction code. There are a bunch of rules
in the spec regarding the usable life of a CMR collection and
transactions. Whatever you decide, please post a feature request, so
we can track the issue.
Dain, what you need is more real use-cases. This is really basic stuff
which is used in most applications today. I'll be happy to provide you
with more examples of such code that is now performing less optimal in
JBoss. I might sound a bit negative but in reality I am *very* positive
about JBoss, I just start knowing the code better and start seeing its
limitations and strengths.
What I will do is write feature requests about specific CMP issues like
this one. Good examples with detailed descriptions and code examples.
That should help for your 4.0 design and maybe some of those
improvements can be implemented for 3.x. I think 3.0 and 3.2 are really
important because to be honest I don't see 4.0 available for probably
at least another year. This is not bad, it is just the way it works.
JBoss went through the same release cycle with 2.4 -> 3.0.
So, here is my first take at the collection problem.
What is needed is something that Hibernate calls Lazy Loading or Lazy
Initialization. This means that a call like getUsers() returns a smart
collection that knows about the (SQL) query that backs it. I think
almost *all* database access can be delayed, maybe even the initial
select. Except when it is a SELECT FOR UPDATE statement i guess,
I'm not sure about that.
What kind of access do we have to a Collection?
iterator() - should only call the original SELECT query and then fetch
a result when Iterator.next() is called or DELETE when remove() is used.
add() - should only do a optional SELECT On the PK to prevent
duplicates and then INSERT
remove() - should only do a SELECT on the PK to find out if the object
was part of the collection and then DELETE
I don't know the EJB spec really that well, so I'm not sure what kind
of problems this would introduce in combination with caching and
transactions.
There are a couple of problems with this approach though.
First of all, the Collection classes don't throw exceptions. So for
example, when Collection.iterator() is called, it is impossible to
throw a database exception. I'm not sure how to solve this. Maybe the
iterator can return a stub null bean that throws an EJBException when
accessed, dunno. Sounds flakey though :-)
'Smart Collections' are easy from a Local Bean when everything is in
the same VM. What happens when the bean is remote? Fallback to standard
Collections or use a proxy object to access the smart collection? How
is that done now?
I'll be happy to discuss this in more detail or even start hacking on
an implementation for 3.x.
S.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
