Hi David. Thank you for your answer.
Let me clarify a few things: Roman is not using cmp. When he says
"bean-managed" he means bean managed transactions not bean managed
persistence. What he tries to do is to read a longitude/latitude value from
an Oracle Spatial column inside a stateless SessionBean. This column has
the proprietary Oracle type MDSYS.SDO_GEOMETRY and the Oracle way to read a
value from such a column is by using the OracleSpatialManager class to
create a GeometryAdapter.
Now the problem is that a connection that he gets from the connection pool,
obviously isn't usable by the OracleSpatialManager. So the questions seems
to come down to: is the Connection returned by the connection pool any
different (and in what way?) from a connection returned directly by the
DriverManager? Can such a connection use Oracle specific JDBC extensions
like Spatial datatypes?
thanks,
Alexander Jerusalem
At 04:53 10.04.01, you wrote:
>Hi,
>
>I can't say I understand entirely why you are getting the results you see,
>but I'm not surprised.
>
>Some comments interspersed below
>
>On 2001.04.09 14:00:36 -0400 Roman Wittchen wrote:
> > As my EJB was bean-managed, I had no problems with the connection pool. I
> > got my connection simply by calling "con = datasource.getConnection();".
> > But since I changed my EJB from bean-managed to container-managed, I am
> > not
> > able to use the ascertained connection as before.
> >
> > For example:
> > I have to put the connection object to a oracle-spatial-method, to
> > receive a
> > sdoAdapter object ... code looks something like this ...
> >
> > GeometryAdapter sdoAdapter = OraSpatialManager.getGeometryAdapter ("SDO",
> > "8.1.6", null, STRUCT.class, null, con);
>
>Where do you get con? I would expect if you get it the same way you get a
>connection for bmp, this ought to work---the connection ought to be
>associated with a XAConnection that has the correct transaction. However
>this is unusual to say the least. Essentially you are mixing cmp and bmp.
> >
> > But unfortunately sdoAdapter is always null. So I changed the code to ...
> >
> > GeometryAdapter sdoAdapter = OraSpatialManager.getGeometryAdapter ("SDO",
> > "8.1.6", null, STRUCT.class, null, DriverManager.getConnection
> > ("jdbc:oracle:thin:@xxx:nnnn:xxxxxx","user", "pw"));
>
>Here you are getting a connection directly from the driver manager...
>bypassing all pooling and transaction management. You may get a
>GeometryAdapter but any work you do on it will be outside the container
>managed transaction.
> >
> > And then it works, ... but I don't want to use this possibility, because
> > the
> > configuration code is hard-coded.
> >
> > Does anybody know, why this is so ?
> >
> > And another peculiar thing is, that, if i change the EJB back to
> > bean-managed, only the connection-pool variante works, and the hard-coded
> > drivermanger variante does not work anymore (then ... the sdoadapter
> > object
> > is null).
>
>Again, not surprising that it doesn't work, since you are mixing pooled
>connections connected to XAConnections and non pooled connections expected
>to manage their own transactions.
> >
> > Help is appreciated.
> >
> > Best regards,
> > Roman Wittchen
>
>I don't know what this GeometryAdapter is, but if you need a connection to
>get one, you should be getting the connection from the pool so the
>transaction is under container control. Is there some reason not to use
>bmp for this? In any case you need to get a connection yourself.
>
>
>I think a more sophisticated approach here that would let you do cmp would
>be to write a resource adapter for oracle connections + GeometryAdapters,
>presumable extending the CCI version of the example BlackBox adapter from
>sun. This would work with the jbosscx JCA implementation. However, after
>you do this to really get cmp without having to write code that directly
>accesses a geometryAdapter you would have to change JAWS very
>substantially. On the other hand, the changes might be very little more
>than the changes needed to make JAWS work with the CCI - blackbox (which I
>haven't examined thoroughly yet).
>
>It's even possible that Oracle might be working on such a resource
>adapter... who knows...
>
>Hope this is a little helpful.
>
>David Jencks
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
>_______________________________________________
>JBoss-user mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
