servlet interprocess communication

[Ariffin Ahmad]

my problem goes like this:
i want to create an objest, a class actually, and then put it in the memory. then, there will be one servlet that manipulate, get and set the variable in that class. after that, or at the same time, there will be another servlet that take a value from the object and then print it. how can i do that?..
i tried getServletContext().setAttribute(name, object), but it seem like it only holding the copy of the object, not the reference. so that, any changes that i made after calling setAttribute will not affected the object which in the memory....
Help!.....

[Tim Holloway]

That didn't completely translate, but one solution is to make the object an Enterprise JavaBean. EJB's have builtin transaction support and serialized access to the object's methods - including the set/get methods.

[Steve Granton]

Hi,
I'm not sure that the heavy weight approach of EJBs is required here.
In my company we often tie objects to the Application Context - object pools and the like. As long as you ensure that the modification is thread-safe then there isn't usually a problem.
I would say that you should ensure that you are storing a reference to your object in the Application context rather than the object itself.
Cheers,
Steve

[William Brogden]

Lets not get too far afield with our nomenclature here. You always store a reference to an object, not the "object itself". Unless you are serializing the object to a file or something, the JVM memory mangagement handles where the object actually lives.

i tried getServletContext().setAttribute(name, object), but it seem like it only holding the copy of the object, not the reference. so that, any changes that i made after calling setAttribute will not affected the object which in the memory....

If you didn't clone the object, there is still only one instance and changes should be visible where ever there is a reference to it. I am betting your problem lies elsewhere.
Bill

[Ariffin Ahmad]

Originally posted by Steve Granton:
Hi,
I'm not sure that the heavy weight approach of EJBs is required here.
In my company we often tie objects to the Application Context - object pools and the like. As long as you ensure that the modification is thread-safe then there isn't usually a problem.
I would say that you should ensure that you are storing a reference to your object in the Application context rather than the object itself.
Cheers,
Steve

can u please show me an example on how to do it that way....

[Ariffin Ahmad]

Originally posted by William Brogden:
Lets not get too far afield with our nomenclature here. You always store a reference to an object, not the "object itself". Unless you are serializing the object to a file or something, the JVM memory mangagement handles where the object actually lives.

If you didn't clone the object, there is still only one instance and changes should be visible where ever there is a reference to it. I am betting your problem lies elsewhere.
Bill

my code was like this...
on first servlet:

public void init()
{
   SomeClass someClass = new SomeClass();
   getServletContext.setAttribute("someClass", someClass);
   /**
    *
    ..... do something with someClass here......
    *
    */
}

on second servlet..

public void init()
{
    SomeClass someClass = (SomeClass)getServletContext.getAttribute("someClass");
   /**
    *
    ..... do something with someClass here......
    *
    */
}

what happen was, even i did something on someClass in the first servlet, i can't get changes in second servlet after i called setAttribute.
any advices?