Hi Bruno,

below you can find #setClosed(...) and #finalize() of the modified PB source (will check in this in a few days).

regards,
Armin

/**
 * A stack trace of this broker user.
 * Used when broker leak detection is enabled.
 */
protected String brokerStackTrace;

public void setClosed(boolean closed)
{
    // When lookup the PB instance from pool method setClosed(false)
    // was called before returning instance from pool, in this case
    // OJB have to refresh the instance.
    if(!closed)
    {
        refresh();
        // configurable boolean
        if(brokerLeakDetection)
        {
            brokerStackTrace = ExceptionUtils.getFullStackTrace(
                    new Exception("PersistenceBroker caller stack"));
        }
    }
    this.isClosed = closed;
}


protected void finalize()
{
    try
    {
        super.finalize();
        // if not closed ==> broker leak detected
        if (!isClosed)
        {
String msg = "Garbage collection: Unclosed PersistenceBroker instance detected, check code for PB leaks.";
            if(brokerLeakDetection)
            {
                logger.error(msg + " Broker caller stack is: "
                   + SystemUtils.LINE_SEPARATOR + brokerStackTrace);
            }
            else
            {
                logger.warn(msg);
            }
            close();
        }
    }
    catch(Throwable ignore)
    {
        // ignore
    }
}


Bruno CROS wrote:
Hi Armin, thanks for solution , but i'm not sure i did get it all !!

Can you confirm solution?

Well, i understand i have to override setCLosed method to catch when broker
open (is borrowed), throw an exception to save a stacktrace with a catch.
So , PB remembers his last loan. that's it ?

When finalize is done (that means application is ended ?), if broker is not
closed (how does i known that ?), i have to retrieve the last stored loan
stacktrace, log it and (why not) throw an BrokerNotClosedException. That's
it ?

Does Abandonned mechanism tells the advance stacktrace? that will be so
great.

Imagine : broker xxx, time-out 120 s, borrowed by --- stacktrace ---

I will try it tomorrow, thanks a lot. Armin.

Regards



On 4/25/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to