File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Applets and the fly likes Reagarding Applet accessing database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Applets
Bookmark "Reagarding Applet accessing database" Watch "Reagarding Applet accessing database" New topic

Reagarding Applet accessing database

suman paul

Joined: Feb 19, 2003
Posts: 19
I am getting
access denied (,,resolve)
Code follows
import java.sql.*;
import java.util.*;
import java.applet.*;
import java.awt.*;
public class TestDB extends Applet
private String strPrint = "Teststring";
public void init()

//DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
String connurl = "jdbc racle:thin:@";
Connection conn = DriverManager.getConnection(connurl,"NetSkill","netskill01");
String strQuery = "Select count(*) from tab";
PreparedStatement pstmt = conn.prepareStatement(strQuery);
ResultSet rs = pstmt.executeQuery();
strPrint = rs.getString(1);
catch(Exception exp){
strPrint ="Exception==>"+exp.getMessage();
public void paint(Graphics g){
public void getPermission(){
Properties prop = new Properties();
prop.put("", new File("MyPolicy.policy"));

Policy file
grant {
permission "developer",
permission java.lang.RuntimePermission
permission java.util.PropertyPermission
"file.encoding", "read";

could anyone help me in this scenario.I extracted and put it in the same codebase.And the Applet class file is in the sam codebase.After that only its recognising all classes but getting this exception.Though sun says
we don't need policy file as its loaded from codebase and accessing the server there.So what is the solution??
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
hi suman,
the problem it seems the database machine- datbase machine is not accessible from ur applet.
instead using jdbc directly from the applet my suggestions would be following,
1. use jdbc connection from a servlet and then let applet communicate directly with the servlet to run any query and get any results
2. use XML based communication to send anything to the server where a servlet would interpret it and dump it to the database and give results back in XML format which Applet can interpret (essentially this is the same case as 1st option but with XML data exchange rather than direct URLCOnnection communication b/w applet/servlet)
3. use RMI from the applet and let the RMI object on the server to handle the database communication

the reason we should avoid using jdbc from the applet are-
1. "the client machine needs to have the jdbc driver on their machine to make it work". We can of course put that jdbc driver in the CODEBASE for client download but if the driver is big then it is unnecessary download for clients apart from the applet code itself
2. this design won't be much scalable/flexible. what if u change the database from oracle to informix or something?? u end up chaning the applet code and the html for the applet and let clients download new jdbc driver via the CODEBASE...
its better to separate database communication from the applet instead...
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

Maulin makes excellent points. I'll say much the same but say it shorter:
When you do JDBC from an applet that's a 2-tier system. Maulin has given some good reasons for avoiding a 2-tier, but here's another:
SQL Slammer
A 3-tier system wouldn't have the database server exposed directly to the internet. Thus, the server is better protected. Also, you wouldn't have to sign the applet or put server-dependent code in the applet.
3-tier is more expensive than 2-tier. It's more complex and there's some additional runtime overhead. But it's usually worth it.

An IDE is no substitute for an Intelligent Developer.
Chang Fred

Joined: Mar 26, 2003
Posts: 1
Is there any code example for RMI access from
My web server is IIS so servlet is not feasible
and I'm not familiar with RMI.
Best Regards
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

I don't think this question directly relates to the topic, so you might not get as many good answers as you would have if you'd started your own topic. But maybe I can help a little.
The original question here was applets and JDBC, so I figure that maybe you're looking for database access from an applet. For a 2-tier solution you don't need a servet/JSP server. Applets can be downloaded from almost ANY web server, including Apache and IIS.
Once the applet has downloaded and started, if it's using JDBC, that doesn't go to a Java server either. In most cases, the JDBC request goes directly to the database server and not a web server. For example, the JDBC drivers for SQL Server build up a TCP/IP request that goes to the server's TCP/IP port (normally that's port 1433).
To do actual client/server programming with IIS, doesn't work, I don't believe. You could do requests to MTS, but that would actually be a CORBA request, since RMI is Java-to-Java, and not Java-to-VB or Java-to-C/C++.
For any of the above solutions, however, you can only do work using a signed applet, as each one of them needs some sort of privileges beyond what the applet sandbox permits. A lot of times you'll get better and more maintainable results by simply using a 3-tier solution. An unsigned applet can send requests for data (and updated data) back to the same server it came from (even if it's running IIS) using a process known as HTTP Tunnelling.
Another good reason for 3-tier solutions I didn't mention before but should have is that CORBA, RMI, and most JDBC connections are done via special TCP/IP ports. You don't want that for an applet that's going to be used on the Internet. Many companies only allow a very restricted set of TCP/IP ports to go through their firewalls, so if you try and access port 1433 at a company that only allows access through ports 80, 443 and 8080 (the well-known HTTP and HTTPS ports), your applet won't run.
It is sorta covered in the JavaRanch Style Guide.
subject: Reagarding Applet accessing database
It's not a secret anymore!