Hello Everyone..
i have a scenario where i need to save the state of an object for further use...lets suppose a transaction is going on and if it gets cancelled at a certain level...in that case i need to revert to the original state...
there are two solutions to this problem..either i make a clone of the object at the very start of the object and in case the transaction gets cancelled i can carry on with the start state again...but another solution is that i serialize the object via a file and can regain the state when needed..now what i need to figure out is that which would be more efficient and have less performance effect...if i consider the scenario of cloning a lot of memory space/resources would be utilized (lets suppose 1000 users carry on the same operation at the same time) and since the objects are gonna be in memory there would be a need garbage collection for each and every object which will again be an overhead..etc. but if i serialize the object and then i I/O overhead would create a bottleneck...

Can someone commect on this.

I don't get your point at all. if it is a TRANSACTION then that implies that if it fails in the middle it is going to get back to the original state right? we have COMMIT for that very reason, isn't it?
vijay

Well just take out the concept of a transaction as in a real sense...just take it as an object is changing it states from time to time for a perticular user request and then then lets suppose that in the middle of that perticular request i need to go to the very first state where it started serving the request(i.e bring an object to a state from where it started).

Well, if that's the case, let's see.
if you go for cloning, memory considerations aside, the design of your class matters a lot since clone() is a protected method you will have to give it a more general access in your class to override it. apart from that. so if that's not a problem then u start worrying about the object itself and it's graph. as far as my knowledge goes cloning gets to be a headache if you go for just a surface copy since the whole of the object graph doesn't get cloned(for instance take any collection class). So if you are not careful enough there and do a deep-copy you will be in soup.
so i guess you might as well go for serialization b'coz though there's going to be an IO problem that will be more due to bad programming than anything else. some efficient code should see u thru.

vijay

I agree with Vijay, I have kind off similar scenario, which you have, in my case we have to also take care of transient data from one transaction being passed to another transaction, anyways to make long story short we are serializing the object instances.

The issue with cloning is you have to be well aware what kind of cloning are you doing shallow or deep, there might be data-structures that you are using which only implement shallow cloning, I believe java.util.Hashtable has this issue if I am not wrong, that you can only shallow clone it, when you call a clone for it, you get the a cloned Hashtable instance but not what is contained within the Hashtable, which definitely can be a problem.

In case of serialization, there is another interface that is the Externalizable interface that allows the developer to implement methods which allow to him to pick and choose the critical instance variables of the object instance to serialize and de-serialize, performance wise this is faster than using the Serializable interface, but the issue with this one is maintenance might be a trade-off.

continuing the discussion, i have done a bit of benchmarking and found that serialization takes much more time than cloning. if performance(in the sense of speed) matters a lot, i guess cloning could be a way out, provided ofcourse one is fully aware of the consequence of copying only the 'surface'. if speed doesn't really matter, perhaps serialization fits the bill quite well.

vijay