Bruno CROS wrote:
using proxies ?
Oh, i see now. Proxy opens and closes broker well. that's it ?
I didn't think to that. Tsss...
I'm sorry.
It seems that i'm looking for my lost brokers since too much time ago.
I guess i'm going to check all my DAOs and all my transactions again (or may
be someone else now ;-) )
You could extend or modify the PersistenceBrokerImpl instance and
override method
public void setClosed(boolean closed)
If set 'false' (PB instance was obtained from the pool) throw and catch
an exception to trace the current method caller.
Override method
protected void finalize()
If current broker instance is not closed print the stack trace from
setClosed-method.
Then it will be easy to find broker leaks. I will add a similar behavior
till next release.
regards,
Armin
Thanks again.
Bye.
On 4/25/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Bruno,
Bruno CROS wrote:
Hi Armin,
Here's is a schematic example :
Consider a service method that returns an object "ProductBean".
ProductBean
is not O/R mapped but the reading calls a second method that read O/R
mapped Product object. Then, relations are followed, to find description
of
his Category (Consider that a product have 1 Category.
2nd method looks like that (classic):
public static Product getProduct(String id) {
PersistenceBroker broker = null;
try {
PersistenceBroker brojer =
PersistenceBrokerFactory.defaultPersistenceBroker();
Identity oid = broker.serviceIdentity().buildIdentity(Product.class,
id);
Product product = (Product) broker.getObjectByIdentity(oid);
return product;
} finally {
if (broker !=null )
{ broker.close();
}
}
}
Frst method looks like that :
public static ProductBean getProductBean(String id)
{ Product p = getProduct(id); // 2nd method call
if (p!=null)
{ ProductBean product = new ProductBean();
product.setDescription(p.getDescription());
product.setID(p.getId());
// and here's the O/R recall
product.setCategoryDescription( p.getCategory().getDescription() );
// now, broker is open... how does it close ?
Sorry, I didn't get it. The Category object associated with Product p
was materialized too when getProduct(id) was called (auto-retrieve is
true). Why does p.getCategory() open a new PB instance?
regards,
Armin
return product;
}
return null;
}
I tried to wrap the code of first method with a tx.open() and tx.abort(),
to
be sure that broker is released at the end with the abort().
thanks
regards.
On 4/25/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Bruno,
Bruno CROS wrote:
Hi,
It seems that read objects with a broker, can read related objects by
auto-retrieve set to "true" despite broker is closed.
I can't see what you mean. When OJB materialize an object with related
objects and auto-retrieve is 'true', the full materialized object is
returned. Thus it's not possible to close the PB instance while object
materialization (except by an illegal concurrent thread).
Or do you mean materialization of proxy references? In this case OJB
try
to lookup the current PB instance and if not found internally a PB
instance is used for materialization and immediately closed after use.
Could you please describe more detailed (with example code)?
regards,
Armin
I suppose that a getDefaultBroker is done, and the borrowed broker is
never
closed (because no reference on it).
Note : This occurred because, application has been written with
several
layers, one for dao, one for services, one for UI.
How can i avoid "auto-retrieves" readings to take brokers in the
PBPool
by
themselves ?
Thanks.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
