tommy k. lee

Greenhorn
+ Follow
since Jun 16, 2004
Merit badge: grant badges
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by tommy k. lee

CallableStatement objects are created with the Connection method prepareCall. The example below creates an instance of CallableStatement that contains a call to the stored procedure getTestData, which has two arguments and no result parameter:

CallableStatement cstmt = con.prepareCall(
"{call getTestData(?, ?)}");

Whether the ? placeholders are IN, OUT, or INOUT parameters depends on the stored procedure getTestData.
Java specifies that it is a security violation to print from a regular (untrusted) applet, just as it is a security violation to read or write files on the user's machine. As a result, Java will automatically prompt the user with "An applet would like to print. Is this OK?", so the user can say "yes" or "no". In order to print from an applet without this prompt, you need to "sign" your applet or set up the security policy on the user's machine to grant your applet the printing privilege.
20 years ago
This article explains how to turn an applet into a standalone application:

http://java.sun.com/developer/technicalArticles/Programming/TurningAnApplet/
20 years ago
Have you made sure that the System Date / Times on the two machines are consistent? JSSE is extremely sensitive to System Time and Dates inconsistencies.
20 years ago
The java.io.File class has an API to automatically create random file names:

static File createTempFile(String prefix, String suffix)

Creates an empty file in the default temporary-file directory, using the given prefix and suffix to generate its name
20 years ago
Did you try disabling compression? You can continue to use the ZIP format to archive all your files, without compressing the individual entries.
20 years ago
Remote object implementations (i.e subclasses of RemoteObject) may use finalize to perform their own cleanup as necessary, for example to deactivate an object server.
20 years ago
In order to work with a proxy, your Java application needs to specify information about the proxy itself as well as specify user information for authentication purposes.

System.getProperties().put( "proxySet", "true" );
System.getProperties().put( "proxyHost", "proxyHost" );
System.getProperties().put( "proxyPort", "85" );

Some proxies require a user to type in a username and password before Internet access is granted. Here's how to perform the authentication:

URLConnection connection = url.openConnection();
String password = "username assword";
String encodedPassword = base64Encode( password );
connection.setRequestProperty( "Proxy-Authorization", encodedPassword );
20 years ago
The transaction timeout values are generally enforced by the container. When the timeout value is exceeded, an XA-type exception is generally thrown by the container.

I generally like to set a large timeout value (5 minutes or more). Sometimes, latencies in the database, network, O/S will cause some transactions to take longer than normal. So to accomodate for these "normal deviations", I don't want to transaction to timeout prematurely.
I've used InstallAnywhere in the past to create stand-alone Java applications. You can use the program to create custom Installers for Java applications, such as specifying shortcuts, agreements, directories, etc... And it will allow you to create a stand-alone executable for your target platform. (Windows, Unix, etc...)
20 years ago
When Oracle receives a SQL statement to execute, it first looks to see if the execution plan already exists in its cache. If the statement does exist in the cache, the previous execution plan is retrieved and used. This reduces the cost of recreating the execution plan, thus saving execution time. The cache can be viewed via the V$SQL table. Looking at the V$SQL table's SQL_TEXT column shows what statements are currently in cache.

One thing to note about how the cache works is that the SQL statements it places in the cache are case-sensitive. Therefore, the following two statements perform the same query, but are seen as two different queries:

SELECT * FROM V$SQL

SELECT * FROM v$sql

They are considered different because the first query references the V$SQL table in all uppercase letters, whereas the second uses all lowercase letters. To prove this, run the following query (note that two entries are returned):
SELECT * FROM V$SQL WHERE SQL_TEXT = 'select * from V$SQL'orSQL_TEXT = 'select * from v$sql'

This can flood the cache with the same query, thus making the cache less useful. To prevent this, always ensure that applications that issue the same query use the same letter case in the syntax.
Based on the OSI 7-layers model, HTTP is an application layer protocol. (layer 7). It uses IP and TCP (layer 3 and layer 4) protocols as its transport. It does NOT support UDP.

Since HTTP uses TCP, it is therefore connection-oriented.

However, what confuses most people is that each web page requests opens multiple HTTP connections to the web server. For instance, if a web page has 5 images, the web browser will likely open 5 different HTTP connections to the web server. After each image is delivered, the connections are closed one-by-one.

This is based on the request-response nature of HTTP. Even though HTTP connections are opened and closed rapidly, the HTTP protocol is connection-oriented since it uses TCP.
Are you using an EJB container to create your data access / persistence classes? (i.e. entity beans , session beans)

Or are you writing a stand-alone JDBC application?

For instance, if you are using an EJB container, the transactions are managed by the EJB container itself. The transactions are usually declared in the deployment descriptors at deploy time, rather than within your application code itself.

However, if you are writing a stand-alone JDBC application, you will need to manage the transactions manually, including roll-backs upon exceptions.

You can find more info @ http://www.javaworld.com/javaworld/jw-07-2000/jw-0714-transaction.html
I've had some success with PoolMan. It provides connection pooling and caching capabilities. I've used it in my prior projects, and it works pretty well.

However, I'm not sure if it is JDBC 3.0 compliant.
The best way to reuse the data access code is to use the DAO (data access object) design pattern.

Take a look: http://java.sun.com/blueprints/patterns/DAO.html