Comments on: Some explorations around Java Stored Procedures in the Oracle Database https://technology.amis.nl/2011/10/22/some-explorations-around-java-stored-procedures-in-the-oracle-database/ Friends of Oracle and Java Mon, 27 Apr 2015 11:47:05 +0000 hourly 1 http://wordpress.org/?v=4.2.1 By: Anonymous https://technology.amis.nl/2011/10/22/some-explorations-around-java-stored-procedures-in-the-oracle-database/#comment-6907 Mon, 24 Oct 2011 09:00:15 +0000 http://technology.amis.nl/blog/13839/some-explorations-around-java-stored-procedures-in-the-oracle-database#comment-6907 Could it be that the java version in the database is too old to support your code?

]]>
By: Lucas Jellema https://technology.amis.nl/2011/10/22/some-explorations-around-java-stored-procedures-in-the-oracle-database/#comment-6906 Sun, 23 Oct 2011 07:08:43 +0000 http://technology.amis.nl/blog/13839/some-explorations-around-java-stored-procedures-in-the-oracle-database#comment-6906 Hi Edwin,

Thanks for thinking along. I had reached that same conclusion with regard to using AQ exposed as JMS to hook into a JEE server. The only drawback for my particular scenario is that this requires additional work in the application server – where I was hoping for a way to configure the JMS Queue to publish onto in the  database and completely stay out of the app server.

However, I concluded earlier on that it will not be possible to create a single, generic solution in PL/SQL and JSP that support any JMS server; it turns out that every JMS implementation (JBoss, GlassFish, WebSphere, WebLogic) requires its own, special client implementation – using dedicated libraries. So instead of being able to create a single JSP with a single set of associated JARs, we will have to create and load a JSP+ JARs for every JMS implementation that needs to be supported.

The best approach seems to be now configure an Advanced Queue in the database expose itself as a JMS Queue that Java Clients then can register to. The following approach:
* during installation of the application, create an Advanced Queue and expose it as JMS Queue (or Topic)
* have the database application publishe to this AQ
* create a MDB (Message Driven Bean) that registers to the AQ based JMS Queue and publish onwards to any desired target JMS Queue or Topic. This MDB can be configured through a properties file or through JMX to target it to the correct target JMS Queue. By adopting this approach, your database implementation stays clean – no complex JSP and JAR installation, no complex configuration of security settings and privileges for the JSP, no special support for every type of JMS implementation that you want/need to support and the full flexibility and decoupling of JMS is still available: your customer sets up the target queue that you should publish to [from the database, directly or indirectly] and the MDB is configured to listen to the AQ based JMS and publish to the ‘real’ JMS Queue. The only complexity introduced is a (standard) Java class (MDB) that should be deployed on the application server used by the customer to run their JMS environment
With WebLogic we could adopt the approach you suggest, with the Foreign JMS Provider. I am not sure how that works out on other application servers that need to be supported.

Lucas

 

]]>
By: Edwin Biemond https://technology.amis.nl/2011/10/22/some-explorations-around-java-stored-procedures-in-the-oracle-database/#comment-6905 Sat, 22 Oct 2011 23:36:49 +0000 http://technology.amis.nl/blog/13839/some-explorations-around-java-stored-procedures-in-the-oracle-database#comment-6905 I think loading java inside is not the best practice, too much objects , think about the public synonyms, hard to remove and restoring, exporting is hard.
Personally the only good way to communicate to the outside world  from the database is AQ. And in that case expose the queue with jms object type as a foreign jms server in WebLogic , this works great on the WebLogic jvm , else build a mdb which reads the aq queue and publish it to a jms queue and uses XA .

]]>