You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Emmanuel Dupont <em...@jwaretechnologies.com> on 2003/06/13 18:28:44 UTC
My Ojb cache doesn't work ??
All,
Here is my code
// Criterias...
Criteria crit = new Criteria();
crit.addEqualTo(Alt_log.LOG_ID_PK,"Essai" );
Query q = QueryFactory.newQuery(Alt_log.class, crit);
// Start the Db transaction
broker.beginTransaction();
altLogEdited = (IAlt_log)broker.getObjectByQuery(q);
tx.lock(altLogEdited, JwtTransaction.READ);
altLogEdited = (IAlt_log)broker.getObjectByQuery(q);
// Release the db connection to PoolConnection manager....
broker.commitTransaction();
tx.commit();
The getObjectByQuery method execute on the both calls a Select in the
Database.
I don't put "true" in the class_descriptor "refresh" option
For me, OJB should'nt look to the database on the second call ...isn't it
????
Tx !
Re: My Ojb cache doesn't work ??
Posted by Thomas Mahler <th...@web.de>.
Hi Emmanuel,
OJB *must* lookup the db during the second query because:
- there could be new data matching the query!
- Maybe the user removed some objects from the cache
- Maybe the Garbage collector or some cache mechanism emptied the cache
But the good news: If there are objects found in query, that are already
in the cache, OJB does not materialize them from the DB (unless you set
refresh="true"), but looks them up from the cache.
Try to measure the execution time of both queries. You'll see the second
execution will be faster due to the cache!
cheers,
Thomas
Emmanuel Dupont wrote:
> All,
>
>
>
>
>
> Here is my code
>
>
>
> // Criterias...
>
> Criteria crit = new Criteria();
>
> crit.addEqualTo(Alt_log.LOG_ID_PK,"Essai" );
>
> Query q = QueryFactory.newQuery(Alt_log.class, crit);
>
>
>
> // Start the Db transaction
>
> broker.beginTransaction();
>
>
>
> altLogEdited = (IAlt_log)broker.getObjectByQuery(q);
>
> tx.lock(altLogEdited, JwtTransaction.READ);
>
>
>
> altLogEdited = (IAlt_log)broker.getObjectByQuery(q);
>
>
>
>
> // Release the db connection to PoolConnection manager....
>
> broker.commitTransaction();
>
>
>
> tx.commit();
>
>
>
>
>
>
>
> The getObjectByQuery method execute on the both calls a Select in the
> Database.
>
>
>
> I don't put "true" in the class_descriptor "refresh" option
>
>
>
> For me, OJB should'nt look to the database on the second call ...isn't it
> ????
>
>
>
>
>
> Tx !
>
>
>
>
Re: Why No Cascading Delete AT All...
Posted by onno <on...@onnos.com>.
Yo Thomas!
> as you can see from the executed SQL:
> "DELETE FROM vacancies WHERE v_id = ?"
> the query is simply translated into a SQL delete statement not caring
> about *any* auto-delete="true" settings!
Indeed - this had me 'flustered' :)
> You have to use broker.delete(aVacancy) to remove the Vacancy instance
> and all associated things!
This fixed it - luckily we have 1 central place (which wraps OJB) so it was
an easy fix :) ...
> Maybe this should be made clearer in the docu...
Yes :) Coz there is no distinction in the docs about delete or deleteByQuery
(there reason we used deleteByQuery - is for mass deletes - it seemed a bit
silly to first retrieve all of them just before finishing them off - ie only
the 'linked' fields should be used, not so much the actual data) I figured
that using deleteByQuery OJB would take care of that 'nasty' business :)
Once again for clearing it up - our database got very big too quick :)
Onno
Re: Why No Cascading Delete AT All...
Posted by Thomas Mahler <th...@web.de>.
Hi Onno,
as you can see from the executed SQL:
"DELETE FROM vacancies WHERE v_id = ?"
the query is simply translated into a SQL delete statement not caring
about *any* auto-delete="true" settings!
You have to use broker.delete(aVacancy) to remove the Vacancy instance
and all associated things!
Maybe this should be made clearer in the docu...
cheers,
Thomas
onno wrote:
> Hiya posted this earlier but no replies maybe due to lack of information,
> but we can't figure it out at all:
>
> //A User Class
> <class-descriptor class="x.User" table="users" >
> <field-descriptor autoincrement="true" column="u_id" id="1"
> jdbc-type="INTEGER" name="id" primarykey="true" />
> <field-descriptor column="u_firstname" id="2" jdbc-type="VARCHAR" />
> </class-descriptor>
>
> //Some Class Using this User
> <class-descriptor class="x.Vacancy" table="vacancies" >
> <field-descriptor autoincrement="true" column="v_id" id="1"
> jdbc-type="INTEGER" name="id" primarykey="true" />
> <field-descriptor name="userId" column="v_userId" id="2"
> jdbc-type="INTEGER" />
> <reference-descriptor name="user" class-ref="x.User"
> auto-retrieve="true" auto-update="true" auto-delete="true">
> <foreignkey field-id-ref="2"/>
> </reference-descriptor>
> </class-descriptor>
>
> yet if we do
>
> (from a retrieved (succesfully) Vacancy)
>
> Criteria criteria = new Criteria();
> criteria.addEqualTo("id", new Integer(aVacancy.getId()));
> Query aQuery = new QueryByCriteria(x.Vacancy, criteria); //
> mBroker.deleteByQuery(aQuery); //
>
> 765 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl - Try to change
> autoCommit state to 'false'
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.singlevm.PersistenceBrokerImpl - deleteByQuery
> x.Vacancy, Query from class x.Vacancy where
> org.apache.ojb.broker.query.Criteria@9d22fc
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl - executeDelete (by Query)
> : Query from class x.Vacancy where
> org.apache.ojb.broker.query.Criteria@9d22fc
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl - SQL: DELETE
> FROM vacancies WHERE v_id = ?
> 68125 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.StatementManager - closeResources was
> called
>
> hence it deletes the Vacancy Succesfully yet the User (whose foreignkey is
> correct in the database) doesn't get deleted even with everything set to
> auto-x = "true"
>
> we tried several mBroker.delete attempts but none did a cascading delete
>
> we are at a loss.
>
> Onno.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Why No Cascading Delete AT All...
Posted by onno <on...@onnos.com>.
Hiya posted this earlier but no replies maybe due to lack of information,
but we can't figure it out at all:
//A User Class
<class-descriptor class="x.User" table="users" >
<field-descriptor autoincrement="true" column="u_id" id="1"
jdbc-type="INTEGER" name="id" primarykey="true" />
<field-descriptor column="u_firstname" id="2" jdbc-type="VARCHAR" />
</class-descriptor>
//Some Class Using this User
<class-descriptor class="x.Vacancy" table="vacancies" >
<field-descriptor autoincrement="true" column="v_id" id="1"
jdbc-type="INTEGER" name="id" primarykey="true" />
<field-descriptor name="userId" column="v_userId" id="2"
jdbc-type="INTEGER" />
<reference-descriptor name="user" class-ref="x.User"
auto-retrieve="true" auto-update="true" auto-delete="true">
<foreignkey field-id-ref="2"/>
</reference-descriptor>
</class-descriptor>
yet if we do
(from a retrieved (succesfully) Vacancy)
Criteria criteria = new Criteria();
criteria.addEqualTo("id", new Integer(aVacancy.getId()));
Query aQuery = new QueryByCriteria(x.Vacancy, criteria); //
mBroker.deleteByQuery(aQuery); //
765 [AWT-EventQueue-0] DEBUG
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl - Try to change
autoCommit state to 'false'
67937 [AWT-EventQueue-0] DEBUG
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl - deleteByQuery
x.Vacancy, Query from class x.Vacancy where
org.apache.ojb.broker.query.Criteria@9d22fc
67937 [AWT-EventQueue-0] DEBUG
org.apache.ojb.broker.accesslayer.JdbcAccessImpl - executeDelete (by Query)
: Query from class x.Vacancy where
org.apache.ojb.broker.query.Criteria@9d22fc
67937 [AWT-EventQueue-0] DEBUG
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl - SQL: DELETE
FROM vacancies WHERE v_id = ?
68125 [AWT-EventQueue-0] DEBUG
org.apache.ojb.broker.accesslayer.StatementManager - closeResources was
called
hence it deletes the Vacancy Succesfully yet the User (whose foreignkey is
correct in the database) doesn't get deleted even with everything set to
auto-x = "true"
we tried several mBroker.delete attempts but none did a cascading delete
we are at a loss.
Onno.