Phani Kumar

Greenhorn
+ Follow
since Feb 15, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
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 Phani Kumar

What are the benefits of using RMI over TCP/IP? I mean, if I want to merely pass some data to a server(it is not a web application) and get the response back, should I go for RMI with remote calls? Or it is more efficient to stick to TCP/IP sockets? Please advice.
17 years ago
My answer is A and D. E is incorrect because Java doesnt restrict an inner class extending from another class, either abstract or concrete.
Synchronizing System.out doesn't guarantee that the two System.out statements are executed atomically. We can have a combination where

1. Thread 1 acquires the lock on System.out, prints 'X'.
2. Thread 2 acquires the lock on System.out, prints 'Y'.
3. Thread 1 acquires the lock on System.out, prints 'X'.
2. Thread 2 again acquires the lock on System.out, prints 'Y'.

Which, clearly is not the desired combination for the output.

Any comments?
[ April 19, 2006: Message edited by: Phani Kumar ]
No Kiran,

I agree with you that calling notify() or notifyAll() doesn't necessarily mean that the thread will give away the lock also. But in options E and F it was clearly mentioned that the thread Z first releases the lock on object A and then calls notify()/notifyAll() on thread X. I think I am correct in that respect. Your comments?
My answer to the second question E and F.

A is incorrect. Though thread X is interrupted, it will not become runnable until the object A's lock is freed.
C is also incorrect. Even though the wait times out, thread X has to acquire the lock on object A before it can continue.
D is incorrect. When an object holding a lock goes to sleep, it will not relinquish them. So there is no way for thread x to acquire lock on object A while thread Z is sleeping.
E and F are correct as the only way thread X can become runnable is thread Z releasing the lock and notifying thread X about it. This is possible using notify() and notifyAll() only.
Simple. The bean will compile and whatever methods you dont declare in your Remote will not be available to your clients. If you dont declare any methods in your remote, the bean wont be accessible at all remotely.
[ March 16, 2005: Message edited by: Phani Kumar ]
I didnt get your requirement, what exactly do you mean by deleting with a single select query? Obviously, Select query doesnt modify the database, it just returns the rows. As far as I know, you can use the ON DELETE CASCADE option available in database. This deletes all the related records from all the dependent tables when you delete the corresponding master record. Hope I am clear.
You can have a thread which calls the external interface and goes to sleep for a specific amount of time. If the external interface responds within that time frame, you will proceed with your normal flow. Otherwise, throw an exception indicating the problem. But I dont know what kind of application yours is. Please note that this approach is preferrable only for stand alone applications. In servlets/EJBs, writing your own thread involves lots of headaches.
In CMT, you have to specify them under ejb-jar.xml. In BMT, use Connection.setTransactionIsolation().
Prashant,
Correct me if I am wrong. According to my knowledge, this is bean specific. For each bean, you will mention the pool size, max beans in pool, min. number of beans to start with etc. So all your beans ejb1, ejb2, ejb3 will be maintained in separate pools.
Have you double checked the database URL that you are using? In your code, this is the only place it can go wrong I guess.
What is the difference between Command pattern and Session Facade? Please correct me if I go wrong. As per my knowledge, both of them aim at reducing the number of remote calls from client and executing all the methods inside a single transaction. Moreover, command calls a SLSB to make contact to the remote server. Then whats the need to have two patterns that serve the same purpose? Anybody please elaborate.
ServletContext is just for that purpose. You can share data among your sevlets using it(provided all these servlets reside in the same servlet container).
19 years ago
Need not! Only your enterprise beans need to be listed in ejb-jar.xml.
See if you are able to ping the database from your machine. It should be a network error as its working from other environment.
19 years ago