|
| Re: [CDO] Transactions [message #555159 is a reply to message #555142] |
Wed, 25 August 2010 15:39   |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Miranda,
the responsible for those transactions getting opened is the so called
CDOViewProvider. Formerly there the user had to open CDOSession /
CDOView explicitly in order to be able to dead with CDO URIs (this is,
URIs refering to CDOObjects in a repository). EMF was not able to open
such views by itself, so we created this mechanism.
org.eclipse.emf.cdo.view.CDOViewProvider
The goal of CDOViewProvider is being able to open a CDOView when a CDO
URI is requested to be resolved (for instance when calling
org.eclipse.emf.ecore.resource.ResourceSet.getResource(URI, boolean))
and no CDOView/CDOTransaction is associated with the ResourceSet in use.
There is a default CDOViewProvider implementation
(org.eclipse.emf.internal.cdo.view.PluginContainerViewProvid er), which
opens CDOTransactions on request, and adopts the conservative approach
of not reusing CDOTransactions. The problem with this mechanism is that
these CDOTransactions are not closed, they are left opened.
If you want, you can contribute your own CDOViewProvider implementation,
establishing your own rules (as reusing always the same CDOView /
CDOTransaction).
This extension point is defined in org.eclipse.emf.cdo, and its named
"viewProviders".
Hope this helps :)
Cheers,
Víctor.
Miranda escribió:
> Hello, all!
> I have problem with transactions. I am persisting objects inside the
> file and I am using EcoreUtil.getUri() to compare them with CDO objects.
> if(EcoreUtil.getUri(fileObject).equals(EcoreUtil.getUri(cdoO bject)))
> So, it works, but I do not know why it opens transactions for every
> comparison and their visible to the client.
> How it is possible to close them or is there another way for comparison?
>
> Thanks!
|
|
|
|
|
| Re: [CDO] Transactions [message #555181 is a reply to message #555167] |
Wed, 25 August 2010 17:57 |
|
Am 25.08.2010 18:43, schrieb Víctor Roldán Betancort:
> Hi Miranda,
>
> I can't seem to understand what you mean with "Because file stores only reference to the object from CDO?". Could you elaborate the problem again?
>
> I'll try to guess your problem. From:
>
> if(EcoreUtil.getUri(fileObject).equals(EcoreUtil.getUri(cdoO bject)))
I may be wrong but that looks plain wrong to me. The resource URIs must already be different and the URI fragments are certainly also different for CDO and non-CDO.
>
> I'll asume you are trying to compare EObjects that are persisted both in a XMIResource and a CDOResource. I would say there is not easy solution for such thing, you would have to use things like the EMF Compare framework, which allows you to compare EObject instances.
>
> Another idea could be modeling a unique identification to your EObject, so independently of the persistence, you'll be able to know if both instances are the same business object.
Yes, in CDO we already have a technical identifier, the CDOID. But that's meaningless outside of CDO, so you're probably off best if you model you own ID.
>
> I guess there are more solution, those are the ones that come to my mind now :P
>
> HTH,
> Víctor.
>
> Miranda escribió:
>> Hi Victor!
>>
>> Thanks for reply! Can you suggest for me another mechanism for object comparison? Because file stores only reference to the object from CDO?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03164 seconds
] 
Search
Help
Register
Login
Home
