-
15. Re: PreFilled Pool Implementation
Flushing the pool also becomes an issue. Once the pool is flushed, all relevant information (Subject primarily) is gone. To support prefilling on a flushed pool I have to be able to reacquire the Subject which is initally done in the BaseConnection manager via the SubjectSecurityManager.
Options:
a) Register the BaseConnectionManager as a listener of the MCP. Reinitialize the pools when flush is called.
b) Inject the SecurityManager into the MCP and replicate the functionality in the BaseConnectionManager
c) Remove prefilling support from Subject based pools altogether. This would allow the pool to be prefilled again when flush is called in an easier manner. -
16. Re: PreFilled Pool Implementation
Regarding the earlier comment about the DynamicLoginConfig, whether the jca security domain is loaded dynamically or statically would not matter. The only type of security domain that can be used with a prefilled pool is one that uses login modules with configuration based identity.
I'm not following what a flushed pool adds to the mix. Once a pool is flushed aren't you just back to an empty pool where any prefilling is subject to the same restrictions as an empty pool? -
17. Re: PreFilled Pool Implementation
Correct, I misspoke about this. What I should have said was any login config that does not provide the subject up front cannot work in this scheme.
As far as the flush goes, its not that the pool is empty, its that it no longer exist. Internally, the pool(s) are kept in a map of SubContexts (basically a wrapper for the InternalManagedConnectionPool). Once a flush occurs, this map is cleared. While containing pool still exists, the sub pools do not. In the case of PoolBySubject, I have to reinitialize the pool with the subject from the login config which JBossManagedConnnectionPool does not have. This is why I was trying to determine what is the best way to do this.
The getSubPool() method is responsible for either returning or creating a SubPoolContext. You will see that the key, subject and connection request info are required.
Let's talk about a scenario, it's easier for me to illustrate the problem:
If you add prefill support to the default Hypersonic DS, when the ConnectionManager is started, the getSubject() method returns the sa identity which is used to intialize the pool. When the pool is flushed, if I don't use the same subject, a completely new pool, with a different identity than the one the user intended is created. For example, when creating a pool with a null subject.
It's just a matter or determining where to get the current Subject() when the pool is flushed. Again, the JBossManagedConnectionPool doesn't have this capability in it today, just the ConnectionManger. It would be easy enough to add, but my 'question' was more along the lines of 'is this the right way to do this' -
18. Re: PreFilled Pool Implementation
And yes, that is the point, the same restrictions, or same criteria apply to a flushed pool as much as a newly initialized pool since they are one and the same thing really.
flush() is destructive in that 'everything' is wiped out:
Connection listeners are removed and their associated managed connections destroyed
The underlying connection pool (InternalManagedConnectionPool) is marked as being shutdown.
The map of sub pools is cleared, thereby becoming empty.
So, it really is starting from scratch again. -
19. Re: PreFilled Pool Implementation
"weston.price@jboss.com" wrote:
It's just a matter or determining where to get the current Subject() when the pool is flushed. Again, the JBossManagedConnectionPool doesn't have this capability in it today, just the ConnectionManger. It would be easy enough to add, but my 'question' was more along the lines of 'is this the right way to do this'
That is correct. The pool is dumb in this repect (and deliberatley so).
It is not its concern to handle the security or transactions,
this is the responsibilty of the connection manager.
The pool is just an object where you say "give me a connection that
matches this information" (Subject and CRI).
The natural solution would be to move the management operations
to the connection manager. Then when it flushes, it might have
enough knowledge about the security integration to understand
whether a prefill is possible.
Unfortunately, the security integration into JCA doesn't expose
much in this respect. i.e. whether there is a single identity
available for the prefill. -
20. Re: PreFilled Pool Implementation
Anyway, at least for the flush(), but not for the initialization,
you have the subject. It is in the key to the pool.public void flush() { synchronized (subPools) { - for (Iterator i = subPools.values().iterator(); i.hasNext(); ) + for (Iterator i = subPools.entrySet().iterator(); i.hasNext(); ) { - SubPoolContext subPool = (SubPoolContext) i.next(); + Map.Entry entry = (Map.Entry) i,next(); + Object key = entry.getKey(); // HERE + SubPoolContext subPool = (SubPoolContext) entry.getValue(); subPool.getSubPool().shutdown(); } subPools.clear(); } }
It would take some polymorphic work to pull the subject and cri out
that object before passing it to getSubPool() for the refill. -
21. Re: PreFilled Pool Implementation
Right, I really, really, really debated doing something like this. However, I was stuck on a few things:
1) It feels kind of hackish, to tell the truth, I am not sure why I feel this way, just seems sort of weird.
2) I didn't know if that information regarding the Subject was valid across flushes of the pool.
Knowing this now makes this a bit easier. -
22. Re: PreFilled Pool Implementation
However, this is the easiest and probably the most convenient approach for this next release. I am sort of regretting backporting this feature for 4.0.5, but it seemed like a natural fit with the other changes going in for background validation and changing the matching policies for connections.
-
23. Re: PreFilled Pool Implementation
Can we introduce a common 'Key' interface into the mix? Or does this break existing compatiblity. It would make the polymorphic stuff easier.
-
24. Re: PreFilled Pool Implementation
The BasePool/InternalManagedConnectionPool stuff is not a public api.
It is implementation Detail.
The public api is [JBoss]ManagedConnectionPool. -
25. Re: PreFilled Pool Implementation
Right understood.
Here is the real kicker, and I think some 'refactoring' :-) is going to have to happen to support this.
Scenario:
PooBySubject is used, prefill is on.
JBoss starts, pool is filled.
User decides they don't want prefill. Set prefill to false.
flush()
User then gets yelled at for not prefilling the pool by management :-)
Sets prefill back to to true.
If the pool had not been used prior to setting this back to true, then the pool is effectively empty, no subjects exist, and the pool cannot be prefilled back to min.
UGH! -
26. Re: PreFilled Pool Implementation
I think, and don't yell at me :-), that it might make more sense to implement prefill for OnePool only for 4.0.5. Once I can rework some of the management stuff, we can always add support for Subject pools later.
It seems that more we reduce the value of prefilling for Subject pools, and add more caveats (we only support x type of login configs etc, etc), the amount of work to support this starts to outweigh the actual benefit.
Very frustrating to say the least. -
27. Re: PreFilled Pool Implementation
Agreed. Just do the simple stuff to start with.
Add the more complicated stuff when you know it is working properly.
It sounds like you can't support changing the prefill flag
at runtime anyway. -
28. Re: PreFilled Pool Implementation
You can change it, and that is the issue. In *-ds.xml file, the element is offered as
true|false
Abscence of the element of course flags it as false. But it is a managed attribute on the JBossManagedConnectionPool which exposes it via JMX.
Again, all of this will work fine with OnePool which, IMO is the way to go for now.