This one time, at band camp, Mattias Bogeblad said:
MB>I'm using <cache-type type="unlimited" capacity="3000"/> on all my entities
MB>in mapping.xml in an attempt to
MB>ensure that I'm caching everything. My thought was that if everything is in
MB>memory the database would never
MB>be accessed but I've been profiling the application and even written some
MB>debug-code in the mysql-jdbc-driver and I'm starting to think some stuff
MB>still gets through and it slows down the test-application very much.
MB>
MB>The statements the jdbc-driver reports are executed are for example when I
MB>execute a rather ordinary query.
MB>
MB>SHOW VARIABLES
MB>SET autocommit=1
MB>SET autocommit=1
MB>SET autocommit=0
MB>SET autocommit=0
MB>null
MB>commit
MB>commit
MB>rollback
MB>rollback
MB>
MB>As you can see no actual data is fetched so the cache is working in that way
MB>but there still seems to be some calls for other reasons.
MB>As these calls repeats for every query to the cache I make (and there are
MB>lots in some sections for application-reasons) the performance is poor
MB>compared to what it could be. My profiler states that about 50% of the
MB>responstime is spent in the mysql-jdbc-driver so I'm wondering if this is a
MB>known problem or if it is a configuration-mistake from my side?
Mattias,
I don't know of any issues with the MySQL JDBC drivers. What version
are you using?
Castor is going to be hitting the database to perform dirty checks on
fields before persisting data. This is to verify that the data hasn't
changed out from under Castor.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
