[mdr-users] Re: Repository Questions

Here's some more information on JDBC concurrency.

- Event notifications definitely won't work; there's currently no 
mechanism for distributing them.

- If you use a database which supports snapshot isolation (e.g. 
Firebird, Oracle, or PostgreSQL), you may be able to get reasonable 
concurrency semantics if you can keep it to 
multiple-readers/single-writer at a time.

- Once a transaction begins, snapshot isolation means that MDR will see 
a consistent view of the database, meaning its local object caches are 
trustworthy for the duration of the transaction.  The only way to see 
changes from other clients is to rollback; this causes MDR to discard 
everything from its local cache at all levels.  If a client hasn't made 
any changes, it should never commit, because that would leave the local 
caches out of sync with the new snapshot state, leading to undefined 
behavior.

- The reason concurrent writers aren't a good idea even with snapshot 
isolation is constraint incoherence.  Within client A, an update may 
preserve constraints, and likewise within client B for a different 
update.  But when the two updates are combined, constraints may be 
violated even when the DBMS doesn't detect any conflicts at the physical 
level.

JVS

> ------------------------------------------------------------------------
> 
> Subject:
> Re: [mdr-users] Repository Questions
> From:
> Martin Matula <[email protected]>
> Date:
> Wed, 10 Aug 2005 10:11:30 +0200
> To:
> [email protected]
> 
> To:
> [email protected]
> 
> 
> Hi Adam,
> please see below for my answers.
> 
> Adam wrote:
> <snip>
>> 4) Does the JDBC implementation allow for concurrent multi-user 
>> access? Can you export from the JDBC to the local Btree easily? At all?
> 
> 
> I am not sure about the multi-user access - there may be certain things 
> that may not work (such as even notifications).
> Exporting JDBC to the local b-tree should be easy. It is definitely 
> doable via XMI import/export. There could be more effective ways of 
> doing this - e.g. being able to connect to both local and remote DB and 
> do copy without the intermediate XML form - but then the extents in the 
> local db would need to have different names than the extents in the 
> JDBC. I don't know if that would be feasible. And nobody experimented 
> with this kind of approach yet.
>