Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Can two sessions be bound in Oracle ?

Re: Can two sessions be bound in Oracle ?

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Thu, 23 Oct 2003 12:51:30 -0700
Message-ID: <1066938705.983256@yasure>


ben brugman wrote:

>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
>>>>>
>>>>>

This looks like bad design.

Those things that are common to more than one module should be in module Z and be installed
with every installation.

Perhaps kept empty until required ... but installed with every installation none the less.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Thu Oct 23 2003 - 14:51:30 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US