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 Bruno CROS <br...@gmail.com> on 2006/04/24 15:09:43 UTC
standalone getDefaultBroker auto-retrieve
Hi,
It seems that read objects with a broker, can read related objects by
auto-retrieve set to "true" despite broker is closed.
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.
Re: standalone getDefaultBroker auto-retrieve
Posted by Bruno CROS <br...@gmail.com>.
Hi Armin,
The detection mechanism works, but i have a strange behaviour, i collected
some open-broker detections. So i had a look into code, and i saw my close
call in a finally clause. this is correct.
So, i don't doubt about "java" finally, but the implementation of my
closeBroker method. In fact, my close Broker is an implementation to close
broker if there is no transaction running on thread. When transaction is
detected, some methods methods use same broker than the transaction does,
this is to work with the objects handled by transaction. So when no
transaction, defautBroker is used, and closed at the end , in finally
clause.
So method does a broker.close() only if
getImplementation.getDatabase(...).getCurrentTransaction
is null (and broker is not null of course)
So, the question is : when currentTransaction is not null ( meaning that
broker will not be close by the method) whereas there is no open
transaction?
I do not have idea at all. I will have a lokk Tuesday.
Thanks for your help. Again.
On 4/28/06, Bruno CROS <br...@gmail.com> wrote:
>
> Yep. I did something like... with an immediate catched exception!! it
> works...
>
> I add a method into PersistenceBrokerFactory to artificially fire all the
> finalize methods. This method call releaseAllInstances and System.gc().
> then Finalize are all fired. It works well.
>
> Will release 1.0.5 come out soon? I need the release with circular
> references update.
>
> else, is there a downloadable nightly build.
>
> Thanks a lot.
>
> Regards
>
> On 4/28/06, Armin Waibel <ar...@apache.org> wrote:
> >
> > 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 <ar...@apache.org> 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 < arminw@apache.org> 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 < arminw@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> > >>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>
> > ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > >>>> For additional commands, e-mail: ojb-user-help@db.apache.org
> > >>>>
> > >>>>
> > >> ---------------------------------------------------------------------
> >
> > >> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > >> For additional commands, e-mail: ojb-user-help@db.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
>
Re: standalone getDefaultBroker auto-retrieve
Posted by Bruno CROS <br...@gmail.com>.
Yep. I did something like... with an immediate catched exception!! it
works...
I add a method into PersistenceBrokerFactory to artificially fire all the
finalize methods. This method call releaseAllInstances and System.gc(). then
Finalize are all fired. It works well.
Will release 1.0.5 come out soon? I need the release with circular
references update.
else, is there a downloadable nightly build.
Thanks a lot.
Regards
On 4/28/06, Armin Waibel <ar...@apache.org> wrote:
>
> 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 <ar...@apache.org> 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 < arminw@apache.org> 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 < arminw@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> >>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
>
> >>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >>>> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: standalone getDefaultBroker auto-retrieve
Posted by Armin Waibel <ar...@apache.org>.
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 <ar...@apache.org> 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 <ar...@apache.org> 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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: standalone getDefaultBroker auto-retrieve
Posted by Bruno CROS <br...@gmail.com>.
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 <ar...@apache.org> 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 <ar...@apache.org> 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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> >>>> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: standalone getDefaultBroker auto-retrieve
Posted by Armin Waibel <ar...@apache.org>.
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 <ar...@apache.org> 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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: standalone getDefaultBroker auto-retrieve
Posted by Bruno CROS <br...@gmail.com>.
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 ;-) )
Thanks again.
Bye.
On 4/25/06, Armin Waibel <ar...@apache.org> 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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: standalone getDefaultBroker auto-retrieve
Posted by Armin Waibel <ar...@apache.org>.
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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: standalone getDefaultBroker auto-retrieve
Posted by Bruno CROS <br...@gmail.com>.
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 ?
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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: standalone getDefaultBroker auto-retrieve
Posted by Armin Waibel <ar...@apache.org>.
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org