Internally the connect should remove the item from the pool and pass it to the driver. If the item is not passed the driver does the real connect(). During $dbh->destroy, the item is deposited to the pool.
Could be done the same was as Apache::DBI. Rebless the handle and have a custom DESTROY. Umm, interestingly, the imp data struct itself is blessed by the DBI into a DBD::_mem::db (::dr/::st) class. Since it's the imp data we're after here we could just rebless the imp data struct and use our own DESTROY there. Cute.
well, my temp solution was to override destroy. I your suggestion is more proper.
It dawned on me early this morning that we hadn't been quite on the same page thus far...
I'd been presuming the existance of a 'pool management thread' that would manage a pool of real dbh's from which it would 'borrow' the imp data to 'loan' to other threads requesting connections.
You have never said that (or I've misread you).
I now realize that the pool is a passive data object and is manipulated directly by the requesting threads. In that scenario the 'thing' to put into the pool is just the copy of the imp data structure.
That's exactly how it's implemented now. The only must thing is that the passive object is created in the parent thread and it's marked as "shared" between all other threads.
(Think of it like a self-service shop full of brains in jars, you come along, pick the brain you want, and take it to another shop, the DBI, where you ask for it to be wrapped up in a new body: $dbh. When you've finished with the body the brain can go back to the shop. Umm, methinks I need some coffee!)
Or look at the code ;) It's trivial.
So, given the 'passive pool' scenario there's no need for 'borrow' or 'restore' because there are no handles in the pool to borrow' from or restore to. (When a newly created dbh has died the hospital, DESTROY, performs a brain removal and gives it to the shop :)
So, we just need $h->remove_imp_data which can be a pretty savage *removal* not a copy, leaving $h brain dead.
Are we on the same (slightly blood stained) page now? :-)
I'm not following your last paras. This is how I see it (and how I implemented it).
The pool stores passive objects. This pool can be manipulated by any thread (with proper mutex locking).
1. The pool can act as a library, where objects are borrowed (moved from the free list to the busy list) and then returned (moved from busy list to the free list)
2. The pool can act as a shop which sells objects (objects are removed from the free list) and which buys the objects back (at the same price!) (objects are placed on the free list). In this scenario there is no busy list, as the shop manages only the inventory of the items it has for sale and doesn't care about items that were purchased.
#1 pros:
- we know how many total connections are open at any given moment
- if the thread dies and we have GC we can recover the connection
- we can free() the pool memory cleanly (since we control all the memory that was allocated)
#1 cons: ???
#2 pros: - no need to manage used connections (simpler pool management/a bit faster?)
#2 cons:
- we don't know how many total connections are open at any given moment
- if the thread unexpectedly dies, we need to figure out how to free() the memory allocated for the item.
Anything else I've missed?
Are we on the same page? I don't see any blood, so I guess we aren't.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
