Win a copy of Spring Boot in Practice this week in the Spring forum!

Nishant Verma

Ranch Hand
+ Follow
since Jun 14, 2006
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nishant Verma

Actually the hibernate uses the session pattern... so it means if the current session does not exists then it provide a new session. But getSession() will never fail.

There is very interesting explanation on the previous post by Cameron. Very well said. And yes you don't have to be better looking to code like this.....hahaha

Rajkumar Kathiresan wrote:1. what would happen if I open the session with "Session.getCurrentSession()" and close the same session with "session.close()" at the end of my method? Whether it will throw any error?
2. If I again I try to open the the session with "Session.getCurrentSession()" it will throw any error?

Thanks. The list was very helpful.
Thanks. The list was very helpful.
The rule of the game - "Survival of the fittest". Superiority complex does not help any organization whatsoever. The bottom line is profitability. Cheap manufacturing rates, less infrastucture cost and better profits - that is what drives any company. If they think H1B workers are slaves then they better be correct since US government is going to increase this quota soon. And who will benefit - the corporations. And who is going to support the H1 visas - the corporations. But this is an understatement for others' calibre - slaves can become king whenever opportunity exists. If they cant find a skilled worker then let them operate the IT company from a place where talent exists. Either import talent or produce it. If you cant fight them then join them - "survival of the fittest" always holds good.

Does people know that real estate pays more than IT. Serious money is still in investment banking, stock exchange, CA and marketing jobs. So what the heck is this fight for. Be realistic, be fantastic, be flexible - welcome changes. I shall stay in IT so long till my second profession becomes self sustaining. Smile for life
[ October 14, 2006: Message edited by: Nishant Verma ]
15 years ago
Ernest Friedman-Hill, Ken Blair, Ilja Preuss

You guys rock really
16 years ago
Thanks NJ. I am bookmarking your post. Looks like you been in US for a long time through a consultant
16 years ago

Truly, I dont see any difference. synchronized arraylist = vector.

Though not 100% sure. Let see if someone thinks otherwise.

16 years ago
I have a question on Serialization. Reference JDK 1.4 Java documentation on ObjectInputStream and ObjectOutputStream.

You can create your own trusted streams by extending ObjectInputStream and ObjectOutputStream. And subsitute a non-serializable object with the serializable one, before writing that to output stream. On the reader end you can resolve, the object and return another to the user. Is this the correct sequence of calls ???

serialization : replaceObject -> writeObject.
deserialization : resolveObject -> readObject. Or resolveobject is called within readObject

Any help will be greatly appreciated.

16 years ago

Originally posted by chinababu illa:
What my doubt is, if we let the stateful session bean associate to the client as long as the client is calling, but once this has to be removed, instead of removing, we can send this stateful bean to the pool. In this case, stateful session bean also doesn't not have any state. And next time, another client comes for the stateful bean, bean has to come from the pool. This way, why can't the scalability be more, also for stateful sesson bean?

If at all the pooling is possible for stateful session beans, the container has to predict the *final* state of the bean, and then assign an appropriate instance from the pool. To add, this requires making a container super-intelligent to predict what the client will actaully do with the bean. Assigning just a new instance from the pool, will squeeze
*neither* the requests *nor* the time taken by the bean object to reach from state A to state B.

My understanding is scalability is the measure of threads that can be running concurrently per client, in a way that every instance in the bean-pool has equal load. To give you a picture lets say that max pool size is m and there are n clients.

For stateful session bean there can be only 1 thread per client running in the container, assuming every bean objects maintains equal load.

For stateless session bean, container can be executing a max of m threads per client concurrently such that every bean object gets an equal load.

This is as good as saying, statless session bean has been serviced m times faster than stateful bean, if they start at the same time. Hope that clears the picture.

[ June 24, 2006: Message edited by: Nishant Verma ]
Thanks !!
API has intercepted the private methods. That was my concern. Your answer helped me a lot. Sun recommends this for serialization - sensitive classes should never be serialized or the sensitive fields should be declared transient. Otherwise any other class can use the ObjectInputStream to read the sensitive fields.

[ June 24, 2006: Message edited by: Nishant Verma ]
16 years ago

private memebers of a class should never be accessible from outside the class. But how do the private methods of Book? Here's the full source code. ObjectInputStream / ObjectOutputStream is intercepting the private methods of Book. Do I call this violation of encapsulation?


class ReadingMaterial {
protected String author;
protected String subject;
protected int yearwritten;
public ReadingMaterial() {}

ReadingMaterial(String auth, String sub, int year) {
author = auth;
subject = sub;
yearwritten = year;

class Book extends ReadingMaterial implements Serializable {

int numpages;
String name;
boolean ishardcover;

Book(int pages, String n, boolean hardcover, String author,
String subject, int yearwritten)
super(author, subject, yearwritten);
numpages = pages;
name = n;
ishardcover = hardcover;

private void writeObject(ObjectOutputStream out) throws IOException {
System.out.println("Called private writeObject....");



private void readObject(ObjectInputStream in)
throws IOException, ClassNotFoundException {
System.out.println("Called private readObject....");

author = (String) in.readObject();
subject = (String) in.readObject();
yearwritten = in.readInt();

public String toString() {
return("Name: " + name + "\n" + "Author: " + author + "\n" + "Pages: "
+ numpages + "\n" + "Subject: " + subject + "\n" + "Year: " + yearwritten
+ "\n");

public class NonSerialSuperExample {

public static void main(String args[]) {

// create a Book object
Book bookorg = new Book(100, "How to Serialize", true, "R.R", "Serialization", 1997);
Book booknew = null;

// serialize the Book
try {
FileOutputStream fo = new FileOutputStream("tmp");
ObjectOutputStream so = new ObjectOutputStream(fo);
} catch (Exception e) {

// deserialize the Book
try {
FileInputStream fi = new FileInputStream("tmp");
ObjectInputStream si = new ObjectInputStream(fi);
booknew = (Book) si.readObject();
}catch (Exception e) {

System.out.println("Printing original book...");
System.out.println("Printing new book... ");
System.out.println("The original and new should be the same!");
16 years ago
Congratulations !! Great score Lisandro


16 years ago
On the client use the following API. This returns a stub (remote reference) to the remote registry. If this call fails then it will throw java.rmi.RemoteException. And you will know that there is problem. What you **cannot** rely after trapping this exception

1. You cannot be sure whether the root cause is the network problem OR the registry outage
2. Regitry may be running fine. But exception might have been thrown due to some problem on the way back.

java.rmi.registry.LocateRegistry.getRegistry(String host, int portNum)

[ June 23, 2006: Message edited by: Nishant Verma ]