Re: [mdr-users] Re: Repository Questions

Adam <[email protected]> Tue, 16 Aug 2005 16:25:39 +0100
Newsgroups gmane.comp.java.netbeans.modules.mdr.user
Message-ID <[email protected]>
John V. Sichi wrote:

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

So so long as you could enforce a Lock on change + some sort of a 
nitification of change (to conected clients) you'd be OK. I.e. only 1 
client can change the extent & the others should then get a "extent 
changed" notification along with a request to refresh the view from the db.

I'm wondering if it would be best to do the shared repository via some 
sort of appserver/webservice.

How would you look at doing a central repository for multiple users? 
Send in the XMI via a webservice, compare to the central repo xmi for 
that extend, have a "merge" jsp page, & then inject the merged xmi as 
the new extent?

I was thinking of something like:

http://pi.informatik.uni-siegen.de/pi/fujaba/difftoolsuite/index.html

Adam


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