This week's giveaway is in the JDBC forum.
We're giving away four copies of Java Database Connections & Transactions (e-book only) and have Marco Behler on-line!
See this thread for details.
Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC forum!

Dana Hanna

Ranch Hand
+ Follow
since Feb 28, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dana Hanna

DB2 has supported java triggers since version 5.2. You can create a trigger that does what you'd like - but you're best off keeping it simple (if you want heavy stuff done, use the trigger to put a message in a queue - or a "queue" table that the other process polls and processes.

Get it>?
Yes, that is possible. Sounds like quite an adventure attempting to do it though. <smile>
15 years ago
Actually, his link proves quite useful to this question.
You are looking for the method:
System.exit(<int value here> ;
The reason that main doesn't return anything is because the main exiting doesn't mean that the program is over. It could have launched other non-daemon threads that would continue execution.
Calling System.exit(int) will end all threads and send the exit code given back to the calling process.
15 years ago

Originally posted by Mani Ram:
The only place where I have found it difficult to track the NPEs are when the code looks something like this

You never know, which object is null here, even with stack traces. You will need some debug code to find out what went wrong.


AMEN! I'd love to strangle a couple contractors at my job for leaving code like this.
15 years ago
I'd have to assume that the result of initial.lookup("MyConverter") is not of type ConverterHome.
Maybe you could print out a debug line after the lookup:
Object obj = initial.lookup("MyConverter");
//what type do we have - is it what we thought?
System.out.println(obj.getClass());
//now narrow it
ConverterHome home =(ConverterHome)PortableRemoteObject.narrow(obj,ConverterHome.class);
Huh? I'm not following you here. 1300 rows represents millions?
Only use a PreparedStatement object from one thread at a time. Declare methods synchronized as needed - the resultset returned also needs to be part of the SAME synchronization. An application server with a good connection pooling and prepared statement caching would help you here. What are you using?
Create an ODBC connection to what? A brand new DB? If so that would require creating an Access database or something else with an ODBC driver.
If an existing DB - you can have your program edit the c:/windows/odbc.ini file to put what you need there.
I am wondering why you'd need this. As part of installation?
include classes12.zip or classes11.zip (depending on the oracle version) in your classpath.
Sorry - JMS is merely and way to send AND recieve requests. However, I think that you are over complicating the problem. Sure - JMS would work, but is it a solution - no? JMS just garauntees asynchronous message delivery. If this is one application all within the same JVM, I don't see why you wouldnt use the Listener or Observable patterns.
Why J2EE?
You could execute the quesry in a seperate Thread, and after a given amount of time, call the cancel() method on the statement object (the original Thread would have to have a reference to it. All in all it's simple, but not for a beginning JDBC or Thread programmer.
You's also want to make this a pattern in your development, and implement it in a generic way - so it's not a simple solution.
I think that the bigger problem is people having direct access to run these types of locking queries on the database!
Transaction type SERIALIZABLE will lock records that have been read while a transaction is open. You specify it at the createStatement or executeQuery - I can't remember which. Or maybe it's at the connection level... Whatever.
Either way, that's what it's for - to lock read records while a transaction is open so that they don't change.
The SQL2K driver is on the MS site somewhere. As far as making it work, getting an API, or finding support - don't get your hopes up. You're lucky to have them even write the Driver.
Good luck getting them to place nice with Java!