Questions on the SessionStore API

[jeff.yuchang]

Hi,

I was working on implementing the RDBMSSessionStore class, and then got following observations on the SessionStore API.

1.  For the create method in the API, we currently have as following:

public java.io.Serializable create(ProtocolId pid, ConversationInstanceId cid) throws IllegalArgumentException, java.io.IOException;

I think we need to have the Serializable Object that we want to initialize, especially on the RDBMSSessionStore class, cause typically it just needs to know how to store/retrieve objects from/to back-end database, the object initialization should be happened somewhere else.

2. I noted that all of API methods throw IOException, I am not sure why we use the IOException here, as we didn't necessary to operate the IO , my opinion would be better to have a  universe unchecked Exception, or even better, don't need to throw the checked exception at all, cause thats what we usually see in the DAO layer. I am also not sure about throwing IllegalArgumentException in the API here either.

3. For the serializable Object that we stored in the database, right now, I just serialized them into byte[] and then save them into the database, one thing that I am worried about is that for the byte[] data type, it is really difficult to do the migration, say DummySession as the session class, but in the 2nd version, the DummySession class got changed a bit, it would be impossible to migrate the 1st version to 2nd version of DummySession class that we used. I am not sure about the Session Object here now, so I would still think that we may need to map the Session object by its fields, but not big serialized byte array. Maybe I am missing some reasons of using Serialized field here.  ;-)

Regards

Jeff

[objectiser]

Jeff Yu wrote:

1.  For the create method in the API, we currently have as following:

public java.io.Serializable create(ProtocolId pid, ConversationInstanceId cid) throws IllegalArgumentException, java.io.IOException;

I think we need to have the Serializable Object that we want to initialize, especially on the RDBMSSessionStore class, cause typically it just needs to know how to store/retrieve objects from/to back-end database, the object initialization should be happened somewhere else.

Yes you are right - the reason for passing serializables is so (for now) the sessions themselves are untyped in respect of the store - however the way I have created the API at the moment, the implementation would need to know the concrete type to be able to create it

So yes the serializable should be passed in - if you could update the API and impl accordingly.

Jeff Yu wrote:

2. I noted that all of API methods throw IOException, I am not sure why we use the IOException here, as we didn't necessary to operate the IO , my opinion would be better to have a  universe unchecked Exception, or even better, don't need to throw the checked exception at all, cause thats what we usually see in the DAO layer. I am also not sure about throwing IllegalArgumentException in the API here either.

This is the first implementation of the API, so I am happy for you to remove the exception declarations for now - and we can always review this later if needed.

Jeff Yu wrote:

3. For the serializable Object that we stored in the database, right now, I just serialized them into byte[] and then save them into the database, one thing that I am worried about is that for the byte[] data type, it is really difficult to do the migration, say DummySession as the session class, but in the 2nd version, the DummySession class got changed a bit, it would be impossible to migrate the 1st version to 2nd version of DummySession class that we used. I am not sure about the Session Object here now, so I would still think that we may need to map the Session object by its fields, but not big serialized byte array. Maybe I am missing some reasons of using Serialized field here.  ;-)

Agree that this can be an issue - however it means that the structure of the session needs to be fixed (i.e. to map onto the fields). Currently the session is associated with another project, and it is difficult to know how that may evolve, and be used in conjunction with Savara. Hence the reason for dealing with sessions as untyped concepts for now.

In terms of the implementation of the session, we can use externalisable to help manage the structure if changes are required (within reason) - obviously wouldn't cope with class name changes.

Regards

Gary