Datasource serializeable (Was: 1.0 status of MessageBundle and non-serializable application resources)

[Johan Compagner <jc...@j-com.nl>]

> As I pointed out in a subsequent message on this thread ... you
> need to avoid the use of the <data-sources> initialization service
> if your container requires context attributes to be serializable.
> In such cases, the app server will provide an alternative means
> (JNDI InitialContext) to gain access to the data sources you need.

Why depend on this?
Why not make the GenericDatabaseSource also serializeable with
externalizeable?

then in the writeExternal(ObjectOutputStream) you close all the connections
and save all the data (properties/maxcount/readOnly/ect/ect)
when the readExternal is called you read all those properties and the
connections will be created with the next call to getConnection()

I only don't know what to do with logWriter at this time the rest is easy to
implement.

Johan

Re: Datasource serializeable (Was: 1.0 status of MessageBundle and non-serializable application resources)

[Johan Compagner <jc...@j-com.nl>]

> > Why depend on this?
> 
> Because it is the standard approach mandated for J2EE applications, to access
> all sorts of resources (including data sources).

But i don't want to get dependend on a J2EE server.
(it's already hard to find a JSP/Servlet ISP on the internet)

But the problem is that i am writing a Web app at this time.
And i want it to run on both environments. (A normal JSP/servlet container and a J2EE container)

Because i want it to run on both environments i must just the lowest common denominator (do i say this right?)
And that is using a Datasource.

 
> > Why not make the GenericDatabaseSource also serializeable with
> > externalizeable?
> >
> 
> I don't think just making it Externalizable (without also declaring
> Serializable) will meet the requirements of the app servers.  Does anyone know?

The interface Serializable is a super interface of Externalizable (it extends)!
The only difference is that Externalizeable gives you complete control (i almost use Externalizable for everyting)
> > then in the writeExternal(ObjectOutputStream) you close all the connections
> > and save all the data (properties/maxcount/readOnly/ect/ect)
> > when the readExternal is called you read all those properties and the
> > connections will be created with the next call to getConnection()
> >
> 
> You could do the same (with only slightly more pain) by creating custom
> readObject() / writeObject() methods for serialization.  I'd be willing to
> accept a patch that does this -- I'm not going to have time to do it in the
> short term.

Yes that is my idee.
Only the logWriter is a problem then.


 
> However, there's a bigger issue here.  The reason an app server wants to
> serialize these things is to distribute them -- and there is no guarantee that
> the database URL, username, password etc. are valid from every single server you
> might distribute them to.  You are also increasing the number of total
> connections that will be established to your database -- perhaps without knowing
> it -- even if the connection parameters are valid.

I will check this out. thx for the info.
 
> It seems to me that data sources belong to an individual server instance.

Not always why?
If the server where it's getting distruted do have everywhere the same connections 
Then the database driver/ url and password should work over every server

johan

Re: Datasource serializeable (Was: 1.0 status of MessageBundle and non-serializable application resources)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Johan Compagner wrote:

> > As I pointed out in a subsequent message on this thread ... you
> > need to avoid the use of the <data-sources> initialization service
> > if your container requires context attributes to be serializable.
> > In such cases, the app server will provide an alternative means
> > (JNDI InitialContext) to gain access to the data sources you need.
>
> Why depend on this?

Because it is the standard approach mandated for J2EE applications, to access
all sorts of resources (including data sources).

>
> Why not make the GenericDatabaseSource also serializeable with
> externalizeable?
>

I don't think just making it Externalizable (without also declaring
Serializable) will meet the requirements of the app servers.  Does anyone know?

>
> then in the writeExternal(ObjectOutputStream) you close all the connections
> and save all the data (properties/maxcount/readOnly/ect/ect)
> when the readExternal is called you read all those properties and the
> connections will be created with the next call to getConnection()
>

You could do the same (with only slightly more pain) by creating custom
readObject() / writeObject() methods for serialization.  I'd be willing to
accept a patch that does this -- I'm not going to have time to do it in the
short term.

However, there's a bigger issue here.  The reason an app server wants to
serialize these things is to distribute them -- and there is no guarantee that
the database URL, username, password etc. are valid from every single server you
might distribute them to.  You are also increasing the number of total
connections that will be established to your database -- perhaps without knowing
it -- even if the connection parameters are valid.

It seems to me that data sources belong to an individual server instance.

>
> I only don't know what to do with logWriter at this time the rest is easy to
> implement.
>

Same issue on PropertyMessageResourcesFactory ... I'm thinking on it.

>
> Johan

Craig