Some questions regarding Derby Store

[Dibyendu Majumdar <di...@mazumdar.demon.co.uk>]

Hi,

I am reading the javadoc documentation and also referring to the  
source code to get an understanding, but it would greatly help me if  
you would answer following questions:

1. I am trying to understand the  
org.apache.derby.iapi.services.context package and what it is used  
for. So far my understanding is this:

a) It is a mechanism for sharing information across multiple modules  
without having to pass parameters.
b) It is a mechanism for stashing away values so that a module can  
get back the stashed values when it is called again.
c) It is a mechanism for associating values with a thread.
d) It is a mechanism for passing error information and cleaning up on  
errors.

The javadoc comments explain how it works, but not really tell why it  
is necessary.

2. Is it possible to have more than one Transaction active in a  
thread? It seems to me from looking at RAMTransactionContext that  
there is a notion of current transaction context. Is this a reason  
why it is necessary to support the nested transaction concept?

3. Following two questions are related to the  
org.apache.derby.iapi.services.monitor package.

a) Is my understanding correct that each module must know what other  
module it depends upon and try to boot the required module? Thus, the  
Monitor system does not inject dependencies, each module needs to  
find any modules it depends upon?
b) Is a Service a synonym for a database instance on disk?


Thank you very much for your help.

Regards


Dibyendu

Re: Some questions regarding Derby Store

[Dibyendu Majumdar <di...@mazumdar.demon.co.uk>]

On 2 Feb 2008, at 00:48, Daniel John Debrunner wrote:

> For a database the primary module as its interface is:
>
> org.apache.derby.database.Database
>
> and for the jdbc layer
>
> org.apache.derby.jdbc.InternalDriver
>
> Note that the jdbc layer used to use java.sql.Driver as the  
> interface, which showed that any interface could be used as the  
> protocol for the monitor. It was only changed to a Derby specific  
> class because java.sql.Driver was not part of JSR169 (jdbc subset)  
> for J2ME/CDC.
>


Thank you.

Regards

Re: Some questions regarding Derby Store

[Daniel John Debrunner <dj...@apache.org>]

Dibyendu Majumdar wrote:

> Thanks - that's very useful. Would you be able to point me to the 
> "primary" modules that exist in Derby?
> Is org.apache.derby.impl.db.BasicDatabase the primary module for the 
> PersistentService?

For a database the primary module as its interface is:

org.apache.derby.database.Database

and for the jdbc layer

org.apache.derby.jdbc.InternalDriver

Note that the jdbc layer used to use java.sql.Driver as the interface, 
which showed that any interface could be used as the protocol for the 
monitor. It was only changed to a Derby specific class because 
java.sql.Driver was not part of JSR169 (jdbc subset) for J2ME/CDC.

Dan.

Re: Some questions regarding Derby Store

[Dibyendu Majumdar <di...@mazumdar.demon.co.uk>]

On 2 Feb 2008, at 00:08, Daniel John Debrunner wrote:
>
> A database instance on disk is an instance of a persistent service,  
> the jdbc driver is an instance of a non-persistent service.
>

Right - I was missing that, and wondering whether the only instance  
of a service was a PersistentService.

> This covers some of it at a high level:
>
> http://db.apache.org/derby/binaries/ApacheDerbyInternals_1_1.pdf
>

Thanks - that's very useful. Would you be able to point me to the  
"primary" modules that exist in Derby?
Is org.apache.derby.impl.db.BasicDatabase the primary module for the  
PersistentService?

Thanks and Regards

Dibyendu

Re: Some questions regarding Derby Store

[Daniel John Debrunner <dj...@apache.org>]

Dibyendu Majumdar wrote:

> 3. Following two questions are related to the 
> org.apache.derby.iapi.services.monitor package.
> 
> a) Is my understanding correct that each module must know what other 
> module it depends upon and try to boot the required module? Thus, the 
> Monitor system does not inject dependencies, each module needs to find 
> any modules it depends upon?

Modules explicitly boot other modules that they need. E.g. the database 
module boots (through the monitor) an access factory and a dictionary 
(system catalog) (and others). The module doesn't care about the 
implementation of the modules it requires, just that they work in the 
configured environment.

So there is no automatic dependency injection.

> b) Is a Service a synonym for a database instance on disk?

Yes, but service is wider than that. A service is a collection of 
modules working together to provide a set of functionality (a service). 
A service can be non-persistent or persistent. A persistent service is 
one who's configuration is derived from a service.properties file, 
though there's no requirement that there is any persistent data or that 
the service.properties file is actually a file on disk (or even a file).

A database instance on disk is an instance of a persistent service, the 
jdbc driver is an instance of a non-persistent service.

This covers some of it at a high level:

http://db.apache.org/derby/binaries/ApacheDerbyInternals_1_1.pdf

HTH,
Dan.