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
