Hi Alessandro,
Alessandro Colantoni wrote:
Hi,
When you use OjbPbDAO of Mandragora, in each method it does (through the
ServiceLocator)
PersistenceBroker broker broker=
PersistenceBrokerFactory.defaultPersistenceBroker();
than at the end of the method it does
broker.close();
I understand that each time it is used a different PB.
I think it is right. For each transaction I get a broker use it and then
close.
That's the way my OjbPbDAO works.
(...and it's correct) But if you want to take advantage from a session
cache on multi findByPrimaryKey calls of the same id or you have to
store hundreds of objects it's a bit a "performance anti pattern" to
close the PB instance on each method call (this evicts the session
cache) or to perform the tx-cycle for each object (this way you can't
rollback the whole operation if something went wrong).
Think it would be useful to allow some kind of PB "inject" in the DAO
implementation (direct or indirect via ServiceLocator) and the DAO never
close the "inject" PB instance.
On insert, update, delete the DAO implementation:
-force a PB-tx (if not running start one and commit/rollback, if running
don't commit at the end)
-or throw an exception if no tx is running on the "inject" PB (more
transparent).
But never allow object modification without a running tx.
regards,
Armin
Anyway remember that Mandragora works with the interface DAO, and if you
think in a better way can be done,
we could write an other DAO implementation, and it is used just changing the
correspondent entry in Mandragora.properties
Regards
Alessandro
On 9/25/07, Hans Novak <[EMAIL PROTECTED]> wrote:
PersistenceBroker.clearCache();
to evict the whole cache
yes, this works, but will increase the database access a lot.
You speaks about the possibility, that ojb and mandragora can use the
same PB ... how ?
I have a dao class, with the broker.
This broker is private and will not used in any other classes !?
The other way is to clear only the obj with a oid - but what for oid ?
(a uniqe id from a filed in database ?)
But this operation willincrase the access to the db too....
The better way is to use the same broker, i think.
Hans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
