Is it ok to be calling reset() on an ObjectOutputStream very frequently?

Question

I read somewhere which has left me unsure and looking for an alternative way. Does calling reset() too frequently cause strain on the network, or unnecessary for this?

I'm sending an object using TCP over an ObjectOutputStream. The objects values get changed before it is written again. Now the same Object but containing different values, without the reset() it resends a reference of the cached object sent before it, which is read to have no changes. I'm not sure if using reset() is a good idea due to such strain. Should I be looking for another way?

Example code would be like:

Socket socket = new Socket(ip, port);

BufferedOutputStream bos = new BufferedOutputStream(socket.getOutputStream());
ObjectOutputStream oos = new ObjectOutputStream(bos);

while(true){
    oos.writeObject(object);
    oos.flush();
    oos.reset();

    object.x++;
}

Chemar

I would call reset() before flush() as a micro-optimisation, but you can call it on every object. – Arabeila

@PeterLawrey Why? As opposed to calling it afterwards? – Rita

@EJP If you reset() before you flush(), the reset() is sent immediately and the other end can drop a reference to the object(s). If you flush(), then reset(), the other end could hold on to the object for some time which is a waste since the next thing it will do is drop it. – Arabeila

Answer 1

Does calling reset() too frequently cause strain on the network

Compared to what? If you need to reset, it is because you need to transmit previously transmitted objects with new values. If you don't need to do that, don't call it. If you do need to do it, network overheads are irrelevant to the functional requirement.

or unnecessary for this?

Eh? Translation please?

I'm sending an object using TCP over an ObjectOutputStream. The objects values get changed before it is written again

So you need to either call reset() or use writeUnshared().

Now the same Object but containing different values, without the reset() it resends a reference of the cached object sent before it, which is read to have no changes.

Correct. So you can't do that.

I'm not sure if using reset() is a good idea due to such strain.

What strain? The only 'strain' is that you are transmitting the new value of the object, and your functional requirement dictates that you must do that. So you don't have a choice.

Should I be looking for another way?

There isn't another way. Either you have to transmit the new value of the object or you don't. If you do, all solutions are essentially equivalent. If you don't, don't.

Rita

Unnecessary for this kind of operation? Like maybe I could setup a UDP connection instead for updating primitives and do it all using bytes. Doing it that way would also remove reset(). But why avoid it if the only problem is that I'm unsure. I've tried writeUnshared() it still doesn't get updated on the other end. The strain is what I'm worried about. I thought by resetting every time would be like closing and opening the connection. In such a short loop that doesn't seem right. Thanks for clearing that anyway, you answered my question. – Bakerman

"Why avoid it if the only problem is that I'm unsure?" is not a logical question. Unsureness isn't a reason to avoid it or not avoid it. You don't have any reason to be unsure after my answer, unless I've said something you don't understand, in which case you should ask me about it. Resetting does not close and reopen the connection. It just clears a local cache and sends a couple of bytes to the peer to tell him to do the same. The writeUnshared() method still shares the objects that are referenced from the object being written: it only 'unshares' that object itself: see the Javadoc. – Rita

I could be running an unnecessary risk at that point. So instead of finding a way around, I'd rather see if it's usable in that way. Knowing whats going on a bit more would help relieve the worry of an unknown error popping up later on, relating to it. I understand enough to be sure of what I'm doing now. After your clarification and some research. Thanks for putting it in more detail. – Bakerman