Hi,
Is anybody there? Is it now clear?
anonymous wrote : No there is no way to create PoolByCri with the patch right
now, if re-authentication is enabled.
What do you mean re-authentication is enabled? How is it configured?
View the original post :
dimonv wrote :
| There are cases in which the same RA provides connections of the different
types. If the client application calls an additional getConnection method of
the RA and provides the meta-info to it, which contains e.g. the java type of
connection, and then casts the returned
vickyk wrote : I don't understand this clearly, may be you can explain this
with respect to the jdbc rar.
This can not be shown on a JDBC example because JDBC always returns a
Connection of the same type. Our JCA connector creates many different
connection types, and therefore multiple CRIs
Once more regarding your quote
vickyk wrote : ...the reauthentication would be decided at the RA level
If an RA states that it support re-authentication, this does not mean per se
that for a specific deployment re-authentication should be used -- this should
be a deployment option, defined in
dimonv wrote :
| This can not be shown on a JDBC example because JDBC always returns a
Connection of the same type. Our JCA connector creates many different
connection types, and therefore multiple CRIs result for the same RA. Therefore
multiple (sub)pools (one per distinct CRI) should be
Because of the reason you mentioned:
vickyk wrote :
| Yes putting them in a single pool will cost more when we need to retrieve
it back, so efficiency would go down and hence we have sub-pools within the
pool, these subpools are created based on Subject/CRI/both(Subject And CRI).
Assume an
dimonv wrote :
| Nevertheless I had a look into the patch suggested by Vicky and have some
comments regarding
org.jboss.resource.connectionmanager.JBossManagedConnectionPool. Even if an RA
supports re-authentication, its connections may not be put into a OnePool per
default, since their
vickyk wrote : What issue do you see here?
There are cases in which the same RA provides connections of the different
types. If the client application calls an additional getConnection method of
the RA and provides the meta-info to it, which contains e.g. the java type of
connection, and then
I'm interesting on re-authentication as well, but my case relates to a non-JDBC
RA (http://www.jboss.org/index.html?module=bbop=viewtopict=155124).
Nevertheless I had a look into the patch suggested by Vicky and have some
comments regarding
Jesper,I am not sure which additional checks you are asking for,these checks
are already there
1)
jesper.pedersen wrote : if the user has specified an incorrect class name,
the driver hasn't been deployed to the lib/ directory,
|
BaseWrapperManagedConnectionFactory::loadReauthClass()
Vicky, I looked over our patch - if you could update it in the area where error
conditions happens - f.ex. F.ex. if the user has specified an incorrect class
name, the driver hasn't been deployed to the lib/ directory, if the method
doesn't exist on the class and so on.
Lets focus on getting
Adrian,
Any review comments on the changes I have attached to the related JIRA?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4238432#4238432
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4238432
The required changes are attached here
https://jira.jboss.org/jira/browse/JBAS-1429
The reauthenitication mechanism with jdbc ra will work when
1) reauthentication-support tag is enabled in ra.xml at
jboss-local-jdbc.rar/META-INF/ra.xml AND jboss-xa-jdbc.rar/META-INF/ra.xml
AND
2) The -ds.xml
Adrian,
Considering the following scenario
Assuming that in MySQL Database we have a Reauth-Schema SCHEMA with the
following tables:
1) Table0
2) Table1
3) Table2
Considering there are 3 users with the following username/password
1) user1/password1
2) user2/password2
3) user3/password3
Now
vickyk wrote : Adrian,
|
| Considering the following scenario
|
Reauthentication has nothing to do with SQL GRANT (authorization).
It is simply about changing the user under which the connection runs.
Anything else is is database configuration (authority not authentication).
View the
Yes, the instructions are still the same (if a little scant of details :-).
It's basically:
1) A configuration option in BaseWrapperManagedConnectionFactory
to define the reauthentication mechanism class
2) Define an interface in org.jboss.resource.adapter.jdbc.vendor for the
reauthentication
Adrian:
I would be interested in developing this JCA re-authentication support, and
also an specific plug-in for the Oracle DB. Since this thread is from 2004, do
your instructions for developing this feature are still correct against the
current release (4.0.5)?
Related Issue:
17 matches
Mail list logo
