-----Original Message-----
>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Sent: Friday, August 31, 2001 5:02 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Castor overhead, cache, etc
>
>
>>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.
I meant "is never done twice".
Thomas
>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
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
