Java Client, Oracle Server

[IHateMyJob2004]

I have java clients that run on a desktop that need to talk/listen to an Oracle server.

The Oracle server will be 10g or 11g. Not up to me and I don't know which version yet. Jave will be Java 6. Possibly 7.

The Java client needs to be able update the Oracle database. When a change occurs, all Java clients need to be notifed.

What technologies shoudl I consider to handle this? Stability and security and the two major concerns. Instead of saying what I am currently considering, I want to hear what others think.

 

[MrChad]

Oracle has some notification capabilities you might be able to use:

http://docs.oracle.com/cd/B28359_01/java.111/b31224/dbmgmnt.htm

 

[beginner99]

Any application server? or do all clients directly talk to database?

I would suggest RMI.
Client submits change -> if successful broadcast to all other clients.

 

[IHateMyJob2004]

RMI is apossibility. I thought there might be a newer tech that is a repalcement for that though.

All clients talk to the database. Clients do not talk to eachother.

The server related code is to be written. Now is a good time in the schedual to determine what technologies to leverage.

THe number of clients will be limited so pulling is not out of the question. I just view pulling as a hack though.

 

[Borealis7]

perhaps JMS messaging?

JMS has a multiple-subscriber messaging system (called "Topics"). your clients register with the JMS Queue on the server, and get notified whenever the topic has a new message.

http://docs.oracle.com/javaee/1.4/tutorial/doc/JMS3.html

 

[IHateMyJob2004]

Oracle has some notification capabilities you might be able to use:

http://docs.oracle.com/cd/B28359_01/java.111/b31224/dbmgmnt.htm

Read up on this. Looks promising. Thanks!


Borealis7,
Currently reading about JMS messaging

 

[hooflung]

What you want is to use a message brokering system like http://activemq.apache.org/ ActiveMQ and the oracle instant client. Clients will attatch to a message que and listen for messages to be published. You'll have a message sent to the que after a successful database transaction.

This practice is one of the foundations to enterprise software. It is one of the many components of SOA.

 

[Oyster]

Oracle has some notification capabilities you might be able to use:

http://docs.oracle.com/cd/B28359_01/java.111/b31224/dbmgmnt.htm

Not a real huge fan of this design. Your probability for failure increases as there is a huge dependency between your database and your application layer.

Just use the built-in JMS API, as some others suggested. You will have finer control over the application (multithreading, notifications, message types, etc.).

 

[IHateMyJob2004]

This gets complicated. I started to explain things. Then decided to delete it and just say it. We need to develop now. We do not have Oracle or anything else available now. For various reasons, jsut assume that we can not install a JMS Provider today.

Which means I can not try out JMS. Is there any way to develop JMS client code without having a JMS Provider available?


NOTE: Started going down the RMI path. Almost got a working test running.

Any other ideas?

 

[cytg111]

No.

KISS all the way, forget RMI / JMS / Appserver stack 4.7 / java stored procedure trigger .... unless you're in it for your CV.

From the java client, poll the database in intervals that suits your needs. How fast must the client react to the data change? Is 1 hour acceptable ? 10 minutes ? 1 minute ?
Even down to the second, i'd still travel this route. No need to go suicide by applicationserver PMS if you dont have to.