Re: Can two sessions be bound in Oracle ?

Thanks for your input and thoughts.

>
> It seems to me that Option 5, "do not separate in application logic,
> entities which are logically related" would apply in the example you give.
> Orders being processed by the General Ledger module but Order Items by the
> stock control module (possibly on a different server) seems to me a daft
> separation.

The reason for modularisation is that some customers want module A others want module B again others want module A and B and then A/B should be intergrated. So we end up in a situation were if A and B are both used that the database should not be seperated. But if sold seperatly they should be seperated. The software is made is such a way that if present the software can interact, but if the other module is not present no interaction is needed.

Then I think that all entities all over the world are 'logically' related. (This is rather filosofical). Limiting the 'world' to our application(s), in our legacy database not all relations were enforced, but although we had hundreds of separate applications, over 5000 tables, most was logicaly related to every other table in the system. Offcourse you can split off a number of functions and tread them as sepparate from the other functions. But there will be logical links, for example if both systems contain any information about people, the systems are logically connected because one person could be present in both systems. (This last filosofical thought is does not influence our designs ???).

>
> There is also Option 6 "define a referential constraint but defer it",
whih
> I don't like but might work or Option 2 which seems to me to be what I am
> trying to say with option 5. In essence the db design should model the
> business requirements and thus if two objects are related then every where
> hat they are dealt with (db,app server, presentation) they should also be
> related.
>

We are designing for Oracle and SQL-server, SQL-server does not know the defered option. In Oracle IOT tables do not support the defered option. (Deferred would not work over two sessions if not bound).

> Of course I'm not an "architect" so what would I know?

I value your opinion.
I am not an "architect" either, but try to support our architects. (Mainly in telling them that some of their ideas should not be used). We use the J2ee environment and the architecs have come up with things like. (The database is not good in Joins so let's avoid joins in the database. It does not matter which software does the constraint checking so the business layer might do that job as well, because then it can have complete control. At some levels the database does not protect against stale data in the database (data read but in the mainwhile altered by another user is still visible for the process) so let's build our own locking system. We are not going to use the sequence system but build our own.).

For most of these things I suspect you know. So although you are not an "architect" you still have a good (gut) feeling what constructs should be avoided.

The modularisation is (as explained) because of market reasons necessary and that is something we have to solve. Some parts of the database are shared, so two modules which overlap, we still have to come up with a solution how to handle this overlap. (Maybe making a third module which only contains the overlap. But keeping the database modules completely seperated (no constraints between the modules) and having the business enforcing those constraints, I think is heading for dissaster. This is from experience and seeing what solutions the architecs come up with.

Well again thanks for your thoughts

ben brugman

>
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
> *****************************************
> Please include version and platform
> and SQL where applicable
> It makes life easier and increases the
> likelihood of a good answer
> ******************************************
>
>
>
>
>
>
> >
> > Each module has a persistency layer which communicates with the
database,
> > the persistency layer maps the data to real tables and fields.
> > Modules are not aware how this persistency layer is implemented. Modules
> > communicate with each other with a 'sort off' messaging system and doing
> > requests etc. they do not know how the request will be implemented. It
> could
> > be that something is calculated (not using a database), but the module's
> can
> > also access its persistency layer which communicates with the RDBMS.
> >
> > Because I have no experience with this type of modular design and
> databases,
> > any insight is welcomed by me.
> > ====================
> >
> > What I am trying to prevent in my organisation that the database get's
> > modularised, where constraints are not implemented in the database but
> > 'only' in the business layer.
> > (Things as we insert a child but the mother is not known yet so the
field
> > must be capable of being/holding NULL, and/or the referential constraint
> can
> > not be forced by the database, because the relation is only 'filled' at
> the
> > end of the transaction).
> >
> > What the developers would like is that they can pospone the enforcing of
> > constraints till the moment they say, alle modules are ready.
> >
> > I would like to meet (over the net) others having the similar
> requirements,
> > or opinions about the above.
> >
> >
> > ben brugman.
> >
> >
> > >
> > >
> > > --
> > > Niall Litchfield
> > > Oracle DBA
> > > Audit Commission UK
> > > "ben brugman" <ben_at_niethier.nl> wrote in message
> > > news:3f94fd54$0$248$4d4ebb8e_at_read.news.nl.uu.net...
> > > > Can Oracle coordinate two or more connections, to prevent lock and
> > > deadlock
> > > > situations between two 'friendly' connections. For example one
> > application
> > > > having two connections but not wanting locks between them.
> > > >
> > > > Similar to :
> > > >
> > > > From the Books on Line from SQL-server :
> > > > "
> > > > Bound connections allow two or more connections to share the same
> > > > transaction and locks. Bound connections can work on the same data
> > without
> > > > lock conflicts. Bound connections can be created from multiple
> > connections
> > > > within the same application, or from multiple applications with
> separate
> > > > connections. Bound connections make coordinating actions across
> multiple
> > > > connections easier.
> > > > "
> > > >
> > > > thanks for your attention,
> > > > ben brugman
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Thu Oct 23 2003 - 03:22:03 CDT