I have read about Serialization theory part , where it says it is required when an object state need to be persisted .
I have written a Web Service Application , Where it will run on different JVMs
I am in the process of improving the performance of my Web Service so I have decided to use transient keyword for some of my Variables inside my Webservice class
I have some questions related to it as what object need to be serialized and what should not be
1.First to start with for my Logger , I will use the keyword transient
For example :
private transient static final Logger logger = Logger.getLogger(Tata.class);
2.But what about the instance variables inside the class ?? do we need to use transient for them or not ??
For example :
String strategyData = null;
String errorText = null;
Properties prop = null;
Please share your inputs .
if the variable is declared as transient, then it will not be persisted. It is the main purpose of the transient keyword.
so all those variables which you do not need to store in the persisted state of the object can be declared as transient.
refer http://www.javabeat.net/tips/168-what-is-transient-keyword-in-java.html for more details
You should mark as transient all fields that cannot or should not be serialized together with other object fields.
Field that is not serializable itself cannot be serialized and therefore must be marked as transient if it belongs to serializable class. The example is class that contains several fields and one of them is Thread. Obviously thread cannot be serialized. Therefore mark it as transient and implement mechanism that creates new thread when object is restored after serialization.
Other example is when field can be but should not be serialized. For example process ID. Assume that your program holds process ID of other process. The process ID itself is int, so there is not problem to serialze it. But it does not have any sense in other environment or in the same environment in several minutes (because that process probably already does not exist).
The web service class itself is never serialized. The data objects that are returned by the web service methods, as well as their arguments, are serialized. They should contain information needed by the recipient of the object.
If some information is not needed by the recipient, and if the object will not cause exceptions with this information set to null, then you can mark it as transient. But if it's not needed by the recipient, it should probably not be part of the object in the first place.
If you're using a logger inside the DTO, then this logger should definitely not be serialized. But make sure to check that the logger is not null each time you're using it, then.
What do you mean by 'run on different JVMs' ?
If it would run simultaneously on several JVMs (a distributed server for instance) than no the variables that represent the state of your object must not be transient.
Otherwise the other servers instances would get your service in an inconsistent state.
visit the link which might be useful to you..
http://javarevisited.blogspot.com/2011/09/transient-keyword-variable-in-java.html
Serialization is used incases where you need to persist state of your object. Or need to trasfer the object state between different machine (or virtual machine, if you are using more than one vm on a single machine) etc.
For ex. If you what the state of the object even after restarting the system, You can use serialization.
Also, You may not required to save all the state in the object. For that you can declare that variable as transient.
If you need only strategyData to be persisted, you can declare the other two variables as transient.
Note. If you need to serialization an object. All the object referred inside must also be Serializable, or you need to declare them as transient.
Related
With Transient variable we can stop serializing the required values, but after deserialization we are getting default values of transient variables and we are loosing the original values. So then what is the need of creating transient variable instead we can skip creating the variable itself. If possible how to get the original value of transient variable.
The idea of a transient variable is that there's no meaning to persist its original value in serialized form, since it wouldn't be in a valid state after de-serialization (think, for example, about a member variable that holds an open Socket).
After de-serialization of the object, the transient variable should be initialized by some method call (for example, the getter of that member may initialize it if it's null).
As for the explanation of Why is there a transient keyword? / What is the use of transient variables? I like to point to this question:
Why does Java have transient fields?
It neatly explains that transient variables are used for i.a. for performance reason, say pre-calculating certain values that come from the combination of other values stored in the object. You need them in your code, but they would only take up valuable space when the object is serialized and sent/stored somewhere.
Another use would be, as mentioned by Eran, to store variables in the object that are necessary for it's function but at the same time are for example dependent on the underlying system.
As for How to get the original value of the transient variable?, there is no clean way to do that afaik. Especially if you serialize and object for transfer between two applications there is no way as the data simply does not exist.
Consider very basic scenario Person class
class Person{
private Name
private DOB
private Age}
In this, storing the Name and DOB makes sense, but storing Age doesn't as it always change on a daily basis, so declare it as transient
and it can be always calculated as Current date - DOB, which will give the accurate Age.
First of all transient keyword is used along with instance variables to exclude them from serialization process. if a field is transient its value will not be persisted.
The perfect use of Transient variable can be seen in Hibernate.
For and example in you Database table there are only two column (name and surname)
but in your POJO entity you are having three variable (name , surname and age) in this situation you can make Transient to age field and you can save your entity without any complain as age variable becomes as transient not going to persist.
I am asking very generic question and the answer can vary from requirement to requirement, but for "general" or "rule of thumb", can we say the following is a good design rule:
The classes to be cached (static/reference data) should be designed as
immutable, with exceptions reasoned.
What could be design/performance issues with the above statement, if this is not true?
#JohnB has a good answer about the underlying data.
If, however, the question is referring to the immutability of the cached classes themselves (which are holding the data in the cache), then the answer is that mutable classes can cause thread-safety issues if the instances of the classes are referenced by multiple threads (as can often happen with data shared via a cache). Additionally, "accidental" modification of the data may occur, where a shared instance is unintentionally modified (because the modifying code did not know that the data was shared).
This is because of what a cache does, which is hold data rather than retrieving it from the data source again. For example, you query the database for a value then put it in a memory-based cache so you don't have to query the DB again. However, if the value in the DB can change then the value in the cache will be out of date and your application will be using the wrong data.
Therefore, caching is best if the data cannot change during the live of the application. If the data can change, then a strategy must be developed to regularly check to see if the data has changed.
What jtahlborn is explaining in other words : an immutable class will provide methods to obtain "static" data.
If your class is immutable, you will NOT have setters except the parameters in the constructor.
Take care making this : immutable classes are not made to be used only once, it would result in a performance loss, since copies of inner attributes have to be done each time you access the get... methods.
Example :
class MyImmutableThing {
private final String myProperty;
MyImmutableThing(String myProperty) {
this.myProperty = myProperty;
}
String obtainMyProperty() {
return myProperty;
}
// note there is no mean to modify the myProperty value : the original value remains ;)
// That's it !
}
I have a simple java class object. I can send the byte code to any of my friends through network. So what is the problem by sending an object without serializing it? Why seriazation is required to send an object. Can't we send it directly?
Your object can contain unserializable objects like InputStreams or DatabaseConnections. If your object (or its predecessors) implements interface Serializable, you code will not compile till the serialization is realy possible.
Well, byte code is what represents a JVM readable format while your serialized object contains behavior and states (instance variables) of an object. they are altogether different thing.
reasons why you would want to send serialized object on network.
Your object's state keep changing, so at any point of time you would want to capture its state and store/send on network.
You may want to store your object's state not in your machine but someone else's.
By serializing you convert your object to the stream of bytes containing your class definition and the props of your object. On the other hand, what's the problem serializing it? It's just the way to do it.
Serialization is managing state of object with client server communication. If you are not making Serializable then it will not manage state of object. if you will try then pass one object from server to client without serialization, it will provide u null object value. so it is indicate that the object which u want to receive at client that is not same as u send. simply through serialization it is not creating new object everytime.so it must required.
Object's state lie's inside JVM . How any other JVM come to know about the state of your object which is inside your JVM , you can transfer blueprint(Class) of your object to your friend via E-Mail ftp or any other file transfer medium but if you have to transfer object across the JVM then you need to persist the state of object and thus you need serialization.
If I have a complex object with hundreds of String fields and objects of objects. Some are implementing Serializable and some aren't.
How would a j2ee server serialize that data in session. Would I expect all data to be returned. Even the objects of objects.
Session.setAttribute(data)
E.g. Session.getAttribute() == data.getData().getData().getData().getData1()
Will the object returned from getData1() return correctly?
(I am using both Tomcat 6 and Websphere 6+)
The servlet spec requires objects that are stored in sessions to be fully serializable, and if you violate the spec it would be perfectly correct behaviour for the container to crash with a NotSerializableException and dismiss the entire session as invalid.
Fortunately, most web containers are more forgiving and will instead keep the session in memory and merely write a warning into the log file. Of course, this can cause problems if you have a lot of sessions containing a lot of data.
Serialization saves the entire object graph*. When your complex object goes in the session the whole thing gets stored. If you want to use clustering then all the objects that are part of your complex object must be Serializable, because at that point your object is getting written to a store that can be accessed by other nodes in the cluster.
EDIT: should've added that being static and transient fields don't get serialized, of course. I try not to include static mutable fields in stuff that needs to be serialized.
When we are deserializing an object, its very difficult to understand that, how it is retriving the object in some certain state? Does it contain any Meta data of the object?
When an object is serialized, the object's class is written to the stream along with the contents of the object's non-transient fields. The deserializer will attempt to load that class (and there are several mechanisms for it to do that), then populate the non-transient fields.
The protocol spec is here: http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html
If by "metadata" you're referring to annotations on the class, then no, they are not serialized with the object itself, but are available on the class. If you mean something else, please describe what you mean.
At a high level, the serialization stream contains the data inside the object and the name of the classes involved, as well as a version number to ensure the class didn't change. It uses that information to make a new instance of an object and fills it with the same data as the old instance. It does this avoiding all of the usual constraints on object creation (the need to call constructors, for example).
One confusing point people have is that they can think the class definition itself is serialized. It is not, just the data it contains with enough information to know which objects to recreate when deserilalized. When the object is deserialized, it has to match the existing class on the class path, the serialization binary data does not contain the class.