>TY> Yes. Castor always create 500 internal objects.
>
>I don't think this is good. There has got to be a way to turn this off.
It's the different between relational and object-oriented.
In the early days of Java, there are articles everywhere claims that you
should think 10 times before you create a new object to avoid performance
hit. It is somehow true that object creation is expensive compare with
assignment, comparison, branching, for example.
But, object creation is very cheap comparing with any other operation
involves network connection, I/O, especially database access (that end up
with many I/O AND network access). Also, JVM is advanced that it smartly
create temporary object on the stack that save a lot of "expensive" malloc
operations.
In short, I don't think you are able to profile the differences for a mere
of 500 objects when iterating thru 500 row of result set.
Castor JDO has a memory lock/cache engine to make sure that loading of the
same row in a table is read done twice. And, no matter how many
modifications you done, assign new values, remove and recreate an object
etc... , the lock/cache engine make sure there are only minimal numbers of
database operation is invoke to the database. That's the real saving that
will make noticeable different.
Certainly, there are some part can be implemented more efficiently. But, I
don't see it as an architecture or design problem at all.
>It comes with a performance hit and is totally useless in many cases.
Some situation requires a software engineer to write code in assembly
language and move the hard drive's heads optimally too...
>I was hoping that in read-only mode Castor will do the following:
>- retrive record(s) according to a query
>- create object or collection of objects based on query results and O/R
>mappings
>- return object/collection to the developer
>- all of the above is done with minimal overhead, with no locks or
>state tracking or etc. Can this be done?
No. It can be skipped, and we're not interested in feature like that, and I
am little bit doubt the actually saving worth the effort. (I think I replied
you or somebody about that a week ago)
The object cache/lock is designed to avoid some more expensive operations.
In OO, you always have a context, (or session) overhead.
For example, employee Cliff and Arnold may "link" to the same group, if they
loaded within the same session, the following should be true
Cliff.getGroup() == Arnold.getGroup(). There can only be done if there is a
session or transaction that keep trace of them, and the session must has a
boundary, or there will be more and more objects to be kept traced by the
session, and OutOfMem will result.
>Why not delegate transactions/locks to the database? DBs do that well
>and Castor is "RDBMS centric", according to the docs.
I mentioned some of that earlier in my email.
Happy long weekend for those who work in US :)!
Thomas
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
