[Pool] force client to return the borrowed object to the pool

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Pool] force client to return the borrowed object to the pool

Edin Ahmetagic
Hello,

could there be an architectual solution to force the clients, that borrows
objects from the pool, to return this back?
An approach coud be, to have an Interface "PoolableObject" which have to be
implemented by the Objects that want to be pooled. In this Interface there
could be an methode returnObject.
I`am not sure if this is really possible, it is only an idea.

Edin
--

--
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Pool] force client to return the borrowed object to the pool

Dirk Verbeeck
Edin,

The technique you propose can already be seen in DBCP.
The real database connections are wrapped with a "poolable" delegating
wrapper. The close method has been overwritten to call returnObject.

But an example inside commons-pool would be nice. In the wiki or on the
website.
Maybe some general code could be written to support this pattern.
Using reflexion/java proxy or even bytecode manipulation you could
implement the "forced" return of the object.

The challenge is of course to find an elegant implementation that
doesn't add too much complexity.

Cheers
Dirk



Edin Ahmetagic wrote:

> Hello,
>
> could there be an architectual solution to force the clients, that borrows
> objects from the pool, to return this back?
> An approach coud be, to have an Interface "PoolableObject" which have to be
> implemented by the Objects that want to be pooled. In this Interface there
> could be an methode returnObject.
> I`am not sure if this is really possible, it is only an idea.
>
> Edin
> --
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Pool] force client to return the borrowed object to the pool

James Carman
If the objects in the pool implement some sort of interface which your
client uses, you could make them return themselves to the pool.  All you
would have to do is wrap them with a proxy (as suggested below) which
implements the "client interface", but make the proxy timeout after a bit of
time, returning the wrapped object to the pool for others to use (if it
hasn't been returned already).  If the client tries to use the proxy object
after it has timed out, a RuntimeException could be thrown.  Though, the
current architecture doesn't allow you to wrap the actual pooled object.  It
returns the pooled object as-is.  But, you would need to be able to create a
new proxy each time an object is borrowed.  That might be a neat addition to
the framework.  
 
-----Original Message-----
From: Dirk Verbeeck [mailto:[hidden email]]
Sent: Friday, June 24, 2005 1:51 AM
To: Jakarta Commons Developers List
Subject: Re: [Pool] force client to return the borrowed object to the pool

Edin,

The technique you propose can already be seen in DBCP.
The real database connections are wrapped with a "poolable" delegating
wrapper. The close method has been overwritten to call returnObject.

But an example inside commons-pool would be nice. In the wiki or on the
website.
Maybe some general code could be written to support this pattern.
Using reflexion/java proxy or even bytecode manipulation you could
implement the "forced" return of the object.

The challenge is of course to find an elegant implementation that
doesn't add too much complexity.

Cheers
Dirk



Edin Ahmetagic wrote:
> Hello,
>
> could there be an architectual solution to force the clients, that borrows
> objects from the pool, to return this back?
> An approach coud be, to have an Interface "PoolableObject" which have to
be
> implemented by the Objects that want to be pooled. In this Interface there
> could be an methode returnObject.
> I`am not sure if this is really possible, it is only an idea.
>
> Edin
> --
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Pool] force client to return the borrowed object to the pool

Edin Ahmetagic
Hi,
I think it would be nice if I could force the client, to return the borrowed
objects to the pool.
As I see other guys think so too. nice :)

I?ve mentioned that it would be an approach to have an interface that have
to be implemnted by
the objects that are "polable". But this could be a problem.
What to do, if the objects that have to be pooled are not modifiable, so
that they can't implement an
interface?
Hmm, there have to be an other approach to solve this.
Any ideas?

Edin
--

I've

> --- Urspr?ngliche Nachricht ---
> Von: "James Carman" <[hidden email]>
> An: "'Jakarta Commons Developers List'" <[hidden email]>
> Betreff: RE: [Pool] force client to return the borrowed object to the pool
> Datum: Fri, 24 Jun 2005 07:02:18 -0400
>
> If the objects in the pool implement some sort of interface which your
> client uses, you could make them return themselves to the pool.  All you
> would have to do is wrap them with a proxy (as suggested below) which
> implements the "client interface", but make the proxy timeout after a bit
> of
> time, returning the wrapped object to the pool for others to use (if it
> hasn't been returned already).  If the client tries to use the proxy
> object
> after it has timed out, a RuntimeException could be thrown.  Though, the
> current architecture doesn't allow you to wrap the actual pooled object.
> It
> returns the pooled object as-is.  But, you would need to be able to create
> a
> new proxy each time an object is borrowed.  That might be a neat addition
> to
> the framework.  
>  
> -----Original Message-----
> From: Dirk Verbeeck [mailto:[hidden email]]
> Sent: Friday, June 24, 2005 1:51 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Pool] force client to return the borrowed object to the pool
>
> Edin,
>
> The technique you propose can already be seen in DBCP.
> The real database connections are wrapped with a "poolable" delegating
> wrapper. The close method has been overwritten to call returnObject.
>
> But an example inside commons-pool would be nice. In the wiki or on the
> website.
> Maybe some general code could be written to support this pattern.
> Using reflexion/java proxy or even bytecode manipulation you could
> implement the "forced" return of the object.
>
> The challenge is of course to find an elegant implementation that
> doesn't add too much complexity.
>
> Cheers
> Dirk
>
>
>
> Edin Ahmetagic wrote:
> > Hello,
> >
> > could there be an architectual solution to force the clients, that
> borrows
> > objects from the pool, to return this back?
> > An approach coud be, to have an Interface "PoolableObject" which have to
> be
> > implemented by the Objects that want to be pooled. In this Interface
> there
> > could be an methode returnObject.
> > I`am not sure if this is really possible, it is only an idea.
> >
> > Edin
> > --
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f?r Mail, Message, More +++

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Pool] force client to return the borrowed object to the pool

Jörg Schaible-2
In reply to this post by Edin Ahmetagic
Hi Edin,

Edin Ahmetagic wrote on Wednesday, June 29, 2005 12:10 PM:

> Hi,
> I think it would be nice if I could force the client, to
> return the borrowed objects to the pool. As I see other guys think so
> too. nice :)
>
> I´ve mentioned that it would be an approach to have an
> interface that have to be implemnted by the objects that are
> "polable". But this could be a problem. What to do, if the
> objects that have to be pooled are not modifiable, so that
> they can't implement an interface? Hmm, there have to be an other
> approach to solve this. Any ideas?

you might have a look at the HEAD version of ProxyToys (http://proxytoys.codehaus.org). The current version 0.1 does obviously contain neither docs nor a solution to the pool problem, but you might build the head version yourself. The ProxyToys source can be checkout out anonymously from the Subversion repository:

svn co svn://svn.proxytoys.codehaus.org/proxytoys/scm/trunk/proxytoys

or browse it:
http://svn.proxytoys.codehaus.org/

The Javadoc for the pool component is quite complete and look at the unit tests for detailed usage.

Basic idea is to decorate all elements in the pool with a proxy and an additional interface. Using the interface, you can manually return the element to the pool. Otherwise the element returns automatically if the garbage collector finalizes the proxy ;-)

In combination with CGLIB you can also proxy non-final classes. Additionally you might create an own interface, that has "compatible methods" to the pooled objects. Note: The pool implementation is very basic by intension, you will have to extend the implementation if you want the pool to create elements on demand, etc.

 ... and yes, I am working on a new release, but first the docs and website have to be ready :)

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Pool] force client to return the borrowed object to the pool

Edin Ahmetagic
In reply to this post by Edin Ahmetagic
I have an idea, for forcing clients to return borrowd objects.
It seems like a scruffy design :-/
You could use the "Reference Objects API" to check how many objects hold an
reference to
the pooled object.
As I suppose:
If the common-pool borrow an object to the client, the client and the pool
hold an reference to the pooled
object. Right.?

Edin
--

>
> Hi,
> I think it would be nice if I could force the client, to return the
> borrowed
> objects to the pool.
> As I see other guys think so too. nice :)
>
> I?ve mentioned that it would be an approach to have an interface that have
> to be implemnted by
> the objects that are "polable". But this could be a problem.
> What to do, if the objects that have to be pooled are not modifiable, so
> that they can't implement an
> interface?
> Hmm, there have to be an other approach to solve this.
> Any ideas?
>
> Edin
> --
>
> I've
> > --- Urspr?ngliche Nachricht ---
> > Von: "James Carman" <[hidden email]>
> > An: "'Jakarta Commons Developers List'" <[hidden email]>
> > Betreff: RE: [Pool] force client to return the borrowed object to the
> pool
> > Datum: Fri, 24 Jun 2005 07:02:18 -0400
> >
> > If the objects in the pool implement some sort of interface which your
> > client uses, you could make them return themselves to the pool.  All you
> > would have to do is wrap them with a proxy (as suggested below) which
> > implements the "client interface", but make the proxy timeout after a
> bit
> > of
> > time, returning the wrapped object to the pool for others to use (if it
> > hasn't been returned already).  If the client tries to use the proxy
> > object
> > after it has timed out, a RuntimeException could be thrown.  Though, the
> > current architecture doesn't allow you to wrap the actual pooled object.
> > It
> > returns the pooled object as-is.  But, you would need to be able to
> create
> > a
> > new proxy each time an object is borrowed.  That might be a neat
> addition
> > to
> > the framework.  
> >  
> > -----Original Message-----
> > From: Dirk Verbeeck [mailto:[hidden email]]
> > Sent: Friday, June 24, 2005 1:51 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [Pool] force client to return the borrowed object to the
> pool
> >
> > Edin,
> >
> > The technique you propose can already be seen in DBCP.
> > The real database connections are wrapped with a "poolable" delegating
> > wrapper. The close method has been overwritten to call returnObject.
> >
> > But an example inside commons-pool would be nice. In the wiki or on the
> > website.
> > Maybe some general code could be written to support this pattern.
> > Using reflexion/java proxy or even bytecode manipulation you could
> > implement the "forced" return of the object.
> >
> > The challenge is of course to find an elegant implementation that
> > doesn't add too much complexity.
> >
> > Cheers
> > Dirk
> >
> >
> >
> > Edin Ahmetagic wrote:
> > > Hello,
> > >
> > > could there be an architectual solution to force the clients, that
> > borrows
> > > objects from the pool, to return this back?
> > > An approach coud be, to have an Interface "PoolableObject" which have
> to
> > be
> > > implemented by the Objects that want to be pooled. In this Interface
> > there
> > > could be an methode returnObject.
> > > I`am not sure if this is really possible, it is only an idea.
> > >
> > > Edin
> > > --
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> --
> 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
> +++ GMX - die erste Adresse f?r Mail, Message, More +++
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f?r Mail, Message, More +++

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]