Well, I haven't implemented this yet, but I don't see how it would help you, either. The effect of setting res-sharing-scope is to prevent a connection from ever getting back in the pool and getting handed back to someone, so your state would be lost immediately.
If you want to be able to assure yourself of being able to get a particular managed connection instance, I suggest you implement a ConnectionRequestInfo with an id in it, and set pooling criteria to ByApplication or ByContainerAndApplication. Modify matchManagedConnection as appropriate.
Note that this essentially eliminates any reason to use the jca:
no transaction management (you are using NoTrans...)
no security (unless your connector implements reauthentication, or there are additional constraints between subject and needed connection instance, asking for a particular connection is not consistent with having more than one possible subject).
maybe I misunderstood what you are trying to do??
> Well, I haven't implemented this yet, but I don't see
> how it would help you, either. The effect of setting
> res-sharing-scope is to prevent a connection from
> ever getting back in the pool and getting handed back
> to someone, so your state would be lost immediately.
It is my understanding of res-sharing-scope="Unshareable" that the connection gets back into the pool when it is closed (via the notification mechanism).
This is exactly what I need (and what I stated as "stateful").
> If you want to be able to assure yourself of being
> able to get a particular managed connection instance,
> I suggest you implement a ConnectionRequestInfo with
> an id in it, and set pooling criteria to
> ByApplication or ByContainerAndApplication. Modify
> matchManagedConnection as appropriate.
This is one option. I also thought about using a Transaction to "isolate" a connection as long the state persists. But res-sharing-scope would be more spec conform, also this might mislead someone to the conclusion that the connector supports transaction ...
> Note that this essentially eliminates any reason to
> use the jca:
> no transaction management (you are using NoTrans...)
> no pooling
> no security (unless your connector implements
> reauthentication, or there are additional constraints
> between subject and needed connection instance,
> asking for a particular connection is not consistent
> with having more than one possible subject).
- after the connection is closed (it looses the state) it should go back into the pool. And since the "open" is the most expensive pooling makes sense.
- the connector could also support reauthentication (if this is needed, for now all connections use default logins).
> maybe I misunderstood what you are trying to do??
What I understand that "Unshareable" is. When a Connection (and the underlying ManagedConnection) is assigned to a Bean it sticks with this Bean until close is called on the connection. After the close it is returned to the pool.
Do I misunderstand the definition of Unshareable?
Hmmm, I think I finally realized what this tag is supposed to mean. My previous understanding was wrong.
As I understand you want to have an ejb that has several method calls, say doA, doB, doC.
doA gets a connection handle and saves it in an object field.
doB uses this handle
doC closes the handle.
Is this correct? Right now the easiest way to simulate this behavior would indeed be to have fake local transactions-- although this may interfere with your real transactions.
I will have to figure out how to implement this.
Yes, that's exaclty what I mean. Basically the usage is the same as for a shared connection (the behaviour you described fits on a SFSB) but the JCA internals have to make sure that the ManagedConnection remains sticked to the Connection until it is closed by the bean.
Regarding the transaction workaround it is also my fear that things get complicated when there are other "real" transactions in a call chain.
I'm going to take a look at the code too, maybee we get things running faster if we share our ideas.
By the way, we would not only get my connector running, but also implement a Spec feature that has general importance.
A simple (maybe naive) attempt would be to not execute the code for
(or even better for CachedConnectionManager?) when unshareable is set. e.g.
For now I just don't know how to get the information that tells me if shareable is set or not (isShareable in org.jboss.metadata.ResourceRefMetaData). Somehow this info has to be requested on runtime since it may be set different for each resource-ref (even for the same connector).
Am I on the right way?
>Yes, that's exaclty what I mean. Basically the usage is >the same as for a shared connection (the behaviour you >described fits on a SFSB) but the JCA internals have to >make sure that the ManagedConnection remains sticked to >the Connection until it is closed by the bean
I think, as per JCA, ManagedConnection will always stick to Connection handle until handle.close() method is called or physical connection problems (so physical connection is closed,no problem in your case) or application server decides to cleanup the connectio handles(this you can manage with the specific application server deployment descriptor for RA)
So then why do u get problems in sharing of connections.
You have security architecture also coming along with JCA.
I am just keen to get know about the actual problem.
> >Yes, that's exaclty what I mean. Basically the usage is
> >the same as for a shared connection (the
> >behaviour you described fits on a SFSB) but the JCA
> >internals have to make sure that the
> >ManagedConnection remains sticked to the Connection
> >until it is closed by the bean
> I think, as per JCA, ManagedConnection will always
> stick to Connection handle until handle.close()
> method is called or physical connection problems (so
> physical connection is closed,no problem in your
> case) or application server decides to cleanup the
> connectio handles(this you can manage with the
> specific application server deployment descriptor for
> So then why do u get problems in sharing of
> You have security architecture also coming along with
> I am just keen to get know about the actual problem.
OK, just read trough the spec, looks like your right (at least partly :-))
The spec allows that there are more than one connection that are associated with a managedConnection (as far as security and transaction scope is not broken). see spec ch 5.5.4. Also there are different strategies described how concurrent access should be handled.
My specific connector to an "old" legacy system has some state stored in the managedconnection. Therefore I need to prevent sharing as described above. Thats wy I need the <res-sharing-scope> attribute. see ch 6.9.
BTW I just read further down the spec and now I have a question for the experts (this is the part where your right)
ch. 6.11 describes the associateConnection scenario. Could it be that the JBoss JCA implementation does not fully comply with the spec?
The spec states that associateConnection may only be called for connections that are associated with a (typically another) ManagedConnection. As far as I know the JBoss JCA sharing relies on the fact that cleanup() is called on a ManagedConnection but the Connection is not closed.
Later the Connection get's associated a ManagedConnection(the same or another one).
This might be a problem if a connector that strongly respects the spec forever invalidates the connection when cleanup is called on the ManagedConnection.
I don't know if this is a good example but if your looking at Suns blackbox examples those would not work with the JBoss JCA manager ...
I haven't looked at the blackbox examples in a while, so I don't know what they do. I also have no reason to think they are spec compliant, even if they are from sun.
I think the spec is exceedingly vague on these issues.
Also, my requests for clarification to the sun guys have gone unanswered.
Here's what I think:
1. connection.close() is very different from managedconnection.cleanup(). close() makes a handle permanently unusable. cleanup removes client-specific state and disconnects all connection handles currently associated with a managed connection. The handles disconnected by a cleanup() call can later be reused after they are reconnected by an associateConnection call. Handles that have been close()d can never be reused.
2. This behavior is required by the apparent requirement to be able to hold connection handles over method boundaries:
(a) ejb A gets a handle, under security context Subject1, and holds onto it.
(b) ejb A is now called under security context Subject2, and uses the same handle. Assuming the adapter doesn't support reauthentication, this means the connection handle saved from step (a) has to be disconnected from its first managed connection and hooked up to one created with Subject2. I believe the only reasonable thing to do with the ManagedConnection created with Subject1 is to call cleanup on it and put it back in the pool. Therefore the connection handle from (a) must still be usable after cleanup is called on the managed connection it was created from.
3. I'd like to reemphasize that the sharable attribute is not implemented yet, even though it is a spec requirement. The spec requires that the same connection manager/mcf be able to be used from shareable and non-sharable ejbs at the same time. If you don't need this, you can probably get the "hold onto it till I close" behavior by setting up a connection manager that has the CachedConnectionManager set to null: I haven't checked recently, this might cause lots of NPE's and not work.