[OJB-developers] More JCA

[Jesper L. <je...@da...>]

Hi again Matthew,

What is the status on your JCA adapter?

Below is my reply to the last mail.

> 4) In the non-managed client, you call commit directly on odmg.Transaction?
> 
> > In the non managed client, don't I have to handle any transaction myself?
> Maybe I misunderstood, but I assumed this would be like using the managed
> connection in a BMT environment.

You're right. I was sleeping!

[Multiple connection & resource sharing]

> Are you sure your connection handling (i.e. 
> OJBMannagedConnection.getConnection) is correctly implemented? I wonder why 
> there's no set or anything holding the currently allocated connection 
> handles. Are you sure this will work correctly if a bean developer obtains 
> multiple connection handles (through OJBConnectionFactory), or if the 
> application server uses resource sharing among bean?
> 
> > This is a really good point, and I admit to not thoroughly looking at how
>  OJB worked, but I assumed that since I was returning the proxy object (A
>  wrapper to the Implementation) and that the implementation used a singleton
>  OJB.... I'm unclear on this.

No, the issue is related to JCA.

Please read the JCA spec section 5.5.4. Especially the part "Connection 
Sharing and Multiple Connection Handles". Then, for example, try look at the 
JCA-compliant JDBC wrapper provided with JBoss as an example how to get 
around the problem.

Another approach is to do it after the book. That is, support resource 
sharing for real. However, this implies supporting and testing all kinds of 
scenarios such as interleaving of multiple transactions on the same 
connection, joining of transaction, thread-safety and more. Also, many of the 
issues are related to XA. For example local transactions have no concept of 
XID, so it's pretty much impossible to do transaction interleaving here. 
Resource sharing from a XA point of view is described in the JTA spec section 
3.4.6.


[resource factory lookup]

>The first question is why the example does not use JNDI ENC and define a 
> resource-ref in ejb-jar.xml? I will argue that all EJB examples provided
> with 
> the JCA adapter must do this.
 
> > obviously this isn't required for it to work, but I'm missing the finer
> points of why to do this. Can you explain. 

Well, using logical JNDI names is the standard way to access external 
resources in EJB 2.0. There's also several good reasons why to actual do it.

Here's a description how to declare resource references in Jboss: 
http://www.jboss.org/online-manual/HTML/ch07s02.html

Also, not doing this and you might get grilled by unpleasant EJB individuals 
when the stuff reaches out to the hardcore J2EE community. I actually once 
got death threats from a J2EE developers when I said that EJB was the perfect 
anti-pattern. Well, I guess one can't compare this with not using resource 
references in ejb-jar.xml :-) However, just take it as a hint then.


> I've looked at other JCA's that
> don't have a resource-ref element in the ejb-jar.xml.

What JCA's did you look at?

>
> Moreover, I do not understand why to think of org.odmg.Implementation as a 
> connection? That is, I think it would be more intuitive if Implementation
> was 
> the resource factory interface and not the connection handle. Also, what if 
> the user creates multiple database connection calling newDatabase, how
> should 
> pooling work then?
 
> > I thought the point was to allow people to connect to multiple databases
> via "newDatabase", and that OJB was handling the pooling itself.

In a managed environment the connection manager of the application server 
controls the pool. OJB should only create connections when told to do so by 
the server.

[snip...]

> > I'm a bit too swamped at work to do the XA work, although I'd love to be
> involved.

Okay. But, if you could look at the connection related stuff and make sure it 
is compliant with the spec, that would be nice. Because, it's your code and 
you know best how the connection handling part of it is supposed to work.

> What is your ability to do some of this work? As you know, the
> code is pretty small, mostly writing wrappers and stuff.

Well, there are several issues around XA, but of course it can be done. 
However, I'll need to try get some connector stuff running in this Trifork 
application server first. Thereafter I'll go for the XA stuff, probably in 
the very near future, say in a couple of weeks.

However, if you can get a robust JCA version up running with local 
transactions that would be a major step also! XA it only needed in the more 
advanced transaction scenarios where several resource adapters are involved. 
I guess most "normal" people don't need these features right away, but I 
could be wrong of course.

> 
> Again, thanks for the excellent feedback. I'm going to do the easier stuff
> on this list then package it up and send it to you, Jesper, if you have some
> time to implement more of your ideas.

What about the non-CCI ODMG factory interface and the BMT stuff we talked 
about, do you intent to look at this also, or what is your plan?

Regards
Jesper