Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Teneo][CDO-Hibernate] Problem with CDOFeatures identity
[Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119496] Tue, 22 April 2008 12:28 Go to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi Martin, Eike,

I have a problem when looking for features with the latest version of
CDO (from CVS). Me and Simon reported a bug a few days ago about
multiple inheritence in CDO and the fix was to add the following code to
CDOClassImpl.java(version 1.35):

public int getFeatureID(CDOFeature feature)
{
int index = feature.getFeatureIndex();
if (index != -1)
{
CDOFeature[] features = getAllFeatures();
while (index < features.length)
{
if (features[index] == feature) <------- Need to be same object!
{
return index;
}

++index;
}
}

return -1;
}

As you can see, in order to find the right feature, it needs to be
contained in the allFeatures[] array. When debugging my code, we've
noticed that the feature I was looking for wasn't in the array, so
probably Teneo did a copy of the features... Is it possible that Teneo
might not be up to date with this CDO fix yet?

Thanks,
Eric
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119522 is a reply to message #119496] Tue, 22 April 2008 13:48 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric,
I have this fix also locally but currently part of the testcases fail because of something related
to EDataType resolving. I can't say if the issue you report is related.

Regarding the code below, do you mean that the feature (passed as a parameter) exists in the
allFeatures but as a different instance (that's why == fails)? Or is the feature completely wrong
and does not even belong to the cdoclass in question?

What is the stacktrace, or where is getFeatureID called from?

gr. Martin

Eric wrote:
> Hi Martin, Eike,
>
> I have a problem when looking for features with the latest version of
> CDO (from CVS). Me and Simon reported a bug a few days ago about
> multiple inheritence in CDO and the fix was to add the following code to
> CDOClassImpl.java(version 1.35):
>
> public int getFeatureID(CDOFeature feature)
> {
> int index = feature.getFeatureIndex();
> if (index != -1)
> {
> CDOFeature[] features = getAllFeatures();
> while (index < features.length)
> {
> if (features[index] == feature) <------- Need to be same object!
> {
> return index;
> }
>
> ++index;
> }
> }
>
> return -1;
> }
>
> As you can see, in order to find the right feature, it needs to be
> contained in the allFeatures[] array. When debugging my code, we've
> noticed that the feature I was looking for wasn't in the array, so
> probably Teneo did a copy of the features... Is it possible that Teneo
> might not be up to date with this CDO fix yet?
>
> Thanks,
> Eric


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119538 is a reply to message #119522] Tue, 22 April 2008 13:56 Go to previous messageGo to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi Martin,

The feature in parameter exists as a different instance in the array.
The feature in parameter is referring to 'myvariable' and in the array,
at the expected index, I see a feature also referring to 'myvariable',
but with a different instance id.

here is the stack trace:

Daemon Thread [Thread-3] (Suspended)
CDOClassImpl.getFeatureID(CDOFeature) line: 111
CDORevisionImpl.getValue(CDOFeature) line: 492
CDOPropertyGetter.get(Object) line: 40
CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line: 46
CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
Map, SessionImplementor) line: 271
SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
Map, SessionImplementor) line: 3673
DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
line: 267
DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
Serializable, EntityPersister, boolean, Object, EventSource, boolean)
line: 181
DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
String, Object, EventSource, boolean) line: 107
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
line: 187
DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
line: 33
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
line: 172
DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line: 27
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
line: 70
SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
SessionImpl.save(String, Object) line: 523
HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
line: 180
CommitTransactionIndication.indicating(ExtendedDataInputStre am) line: 109
CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
BufferOutputStream) line: 46
CommitTransactionIndication(Signal).runSync() line: 143
ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
ThreadPoolExecutor$Worker.run() line: not available
Thread.run() line: not available

Martin Taal wrote:
> Hi Eric, I have this fix also locally but currently part of the
> testcases fail because of something related to EDataType resolving. I
> can't say if the issue you report is related.
>
> Regarding the code below, do you mean that the feature (passed as a
> parameter) exists in the allFeatures but as a different instance
> (that's why == fails)? Or is the feature completely wrong and does
> not even belong to the cdoclass in question?
>
> What is the stacktrace, or where is getFeatureID called from?
>
> gr. Martin
>
> Eric wrote:
>> Hi Martin, Eike,
>>
>> I have a problem when looking for features with the latest version
>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>> about multiple inheritence in CDO and the fix was to add the
>> following code to CDOClassImpl.java(version 1.35):
>>
>> public int getFeatureID(CDOFeature feature) { int index =
>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>> = getAllFeatures(); while (index < features.length) { if
>> (features[index] == feature) <------- Need to be same object! {
>> return index; }
>>
>> ++index; } }
>>
>> return -1; }
>>
>> As you can see, in order to find the right feature, it needs to be
>> contained in the allFeatures[] array. When debugging my code,
>> we've noticed that the feature I was looking for wasn't in the
>> array, so probably Teneo did a copy of the features... Is it
>> possible that Teneo might not be up to date with this CDO fix yet?
>>
>> Thanks, Eric
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119560 is a reply to message #119538] Tue, 22 April 2008 15:01 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Martin, Eric,

Tonight I will have the chance to look at the code and clarify the
expected semantics of the allFeatures array. I can't recall it w/o code ;-(

Eric, did I apply the patch (multi-inheritance) correctly from your point
of view?

Cheers
/Eike


Eric wrote:

> Hi Martin,

> The feature in parameter exists as a different instance in the array.
> The feature in parameter is referring to 'myvariable' and in the array,
> at the expected index, I see a feature also referring to 'myvariable',
> but with a different instance id.

> here is the stack trace:

> Daemon Thread [Thread-3] (Suspended)
> CDOClassImpl.getFeatureID(CDOFeature) line: 111
> CDORevisionImpl.getValue(CDOFeature) line: 492
> CDOPropertyGetter.get(Object) line: 40
> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line: 46
>
CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
> Map, SessionImplementor) line: 271
>
SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
> Map, SessionImplementor) line: 3673
>
DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
> line: 267
> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
> line: 181
>
DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
> String, Object, EventSource, boolean) line: 107
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
> line: 187
> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
> line: 33
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
> line: 172
> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line: 27
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
> line: 70
> SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
> SessionImpl.save(String, Object) line: 523
> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
> line: 180
> CommitTransactionIndication.indicating(ExtendedDataInputStre am) line: 109
>
CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
> BufferOutputStream) line: 46
> CommitTransactionIndication(Signal).runSync() line: 143
> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
> ThreadPoolExecutor$Worker.run() line: not available
> Thread.run() line: not available

> Martin Taal wrote:
>> Hi Eric, I have this fix also locally but currently part of the
>> testcases fail because of something related to EDataType resolving. I
>> can't say if the issue you report is related.
>>
>> Regarding the code below, do you mean that the feature (passed as a
>> parameter) exists in the allFeatures but as a different instance
>> (that's why == fails)? Or is the feature completely wrong and does
>> not even belong to the cdoclass in question?
>>
>> What is the stacktrace, or where is getFeatureID called from?
>>
>> gr. Martin
>>
>> Eric wrote:
>>> Hi Martin, Eike,
>>>
>>> I have a problem when looking for features with the latest version
>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>> about multiple inheritence in CDO and the fix was to add the
>>> following code to CDOClassImpl.java(version 1.35):
>>>
>>> public int getFeatureID(CDOFeature feature) { int index =
>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>> = getAllFeatures(); while (index < features.length) { if
>>> (features[index] == feature) <------- Need to be same object! {
>>> return index; }
>>>
>>> ++index; } }
>>>
>>> return -1; }
>>>
>>> As you can see, in order to find the right feature, it needs to be
>>> contained in the allFeatures[] array. When debugging my code,
>>> we've noticed that the feature I was looking for wasn't in the
>>> array, so probably Teneo did a copy of the features... Is it
>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>
>>> Thanks, Eric
>>
>>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119586 is a reply to message #119560] Tue, 22 April 2008 18:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hey guys,

I can confirm that the allFeatures array, once initialized, should contain pointers to the already existing features of all the superTypes plus the own features.

And I can't remember of any place where CDO copies instance data of a CDOFeature. All the CDOModelElements are considered immutable and appropriate for testing reference equality (just like with EModelElements).

Eric, could you please verify
1) that the element of the allFeatures array occurs somewhere in the features List (possibly in a superType)
2) where your argument to getFeatureID() comes from (did Martin ask this already?)

Cheers
/Eike


Eike Stepper schrieb:
> Hi Martin, Eric,
>
> Tonight I will have the chance to look at the code and clarify the
> expected semantics of the allFeatures array. I can't recall it w/o code ;-(
>
> Eric, did I apply the patch (multi-inheritance) correctly from your
> point of view?
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Martin,
>
>> The feature in parameter exists as a different instance in the array.
>> The feature in parameter is referring to 'myvariable' and in the array,
>> at the expected index, I see a feature also referring to 'myvariable',
>> but with a different instance id.
>
>> here is the stack trace:
>
>> Daemon Thread [Thread-3] (Suspended)
>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>> CDORevisionImpl.getValue(CDOFeature) line: 492
>> CDOPropertyGetter.get(Object) line: 40
>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor)
>> line: 46
>>
> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>
>> Map, SessionImplementor) line: 271
>>
> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>
>> Map, SessionImplementor) line: 3673
>>
> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>
>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>> line: 267
>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>
>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>> line: 181
>>
> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>
>> String, Object, EventSource, boolean) line: 107
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>
>> line: 187
>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>
>> line: 33
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>
>> line: 172
>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt)
>> line: 27
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>
>> line: 70
>> SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>> SessionImpl.save(String, Object) line: 523
>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>> line: 180
>> CommitTransactionIndication.indicating(ExtendedDataInputStre am)
>> line: 109
>>
> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>
>> BufferOutputStream) line: 46
>> CommitTransactionIndication(Signal).runSync() line: 143
>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>> ThreadPoolExecutor$Worker.run() line: not available
>> Thread.run() line: not available
>
>> Martin Taal wrote:
>>> Hi Eric, I have this fix also locally but currently part of the
>>> testcases fail because of something related to EDataType resolving. I
>>> can't say if the issue you report is related.
>>>
>>> Regarding the code below, do you mean that the feature (passed as a
>>> parameter) exists in the allFeatures but as a different instance
>>> (that's why == fails)? Or is the feature completely wrong and does
>>> not even belong to the cdoclass in question?
>>>
>>> What is the stacktrace, or where is getFeatureID called from?
>>>
>>> gr. Martin
>>>
>>> Eric wrote:
>>>> Hi Martin, Eike,
>>>>
>>>> I have a problem when looking for features with the latest version
>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago about
>>>> multiple inheritence in CDO and the fix was to add the following
>>>> code to CDOClassImpl.java(version 1.35):
>>>>
>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>> = getAllFeatures(); while (index < features.length) { if
>>>> (features[index] == feature) <------- Need to be same object! {
>>>> return index; }
>>>>
>>>> ++index; } }
>>>>
>>>> return -1; }
>>>>
>>>> As you can see, in order to find the right feature, it needs to be
>>>> contained in the allFeatures[] array. When debugging my code, we've
>>>> noticed that the feature I was looking for wasn't in the array, so
>>>> probably Teneo did a copy of the features... Is it possible that
>>>> Teneo might not be up to date with this CDO fix yet?
>>>>
>>>> Thanks, Eric
>>>
>>>
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119599 is a reply to message #119586] Tue, 22 April 2008 19:48 Go to previous messageGo to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi Martin, Eike,

I have verified what Eike said:

1) all the elements of allFeatures are indeed present in the features list.
2) The CDOFeature argument is coming from the private member of
CDOPropertyHandler.

I am not that familiar with CDO as I am learning on the go, but here is
what I see:

The CDOPropertyGetter has a tuplizer that contains a cdoClass and in
this cdoClass, I can see the CDOFeature I am looking for (both in the
allFeatures[] array and the features list). But, the revision in the
following piece of code (from CDOPropertyGetter.java):
public Object get(Object target) throws HibernateException
{
InternalCDORevision revision = (InternalCDORevision)target;
return revision.getValue(getCDOFeature());
}

that revision also contains a cdoClass, but this cdoClass does not
contain the feature I am looking for. I can see an equivalent feature
(same attributes, but different instance, just like a copy), but their
pointers differ. And obviously, the cdoClass from the revision is not
the same instance as the one in the tuplizer.

I don't know if all of this clarifies my problem, but I'd like to get
some light on the role of the cdoClass in tuplizer versus the one in the
revision...

Thanks!
Eric

Eike Stepper wrote:
> Hey guys,
>
> I can confirm that the allFeatures array, once initialized, should
> contain pointers to the already existing features of all the superTypes
> plus the own features.
>
> And I can't remember of any place where CDO copies instance data of a
> CDOFeature. All the CDOModelElements are considered immutable and
> appropriate for testing reference equality (just like with EModelElements).
>
> Eric, could you please verify
> 1) that the element of the allFeatures array occurs somewhere in the
> features List (possibly in a superType)
> 2) where your argument to getFeatureID() comes from (did Martin ask this
> already?)
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>> Hi Martin, Eric,
>>
>> Tonight I will have the chance to look at the code and clarify the
>> expected semantics of the allFeatures array. I can't recall it w/o
>> code ;-(
>>
>> Eric, did I apply the patch (multi-inheritance) correctly from your
>> point of view?
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Martin,
>>
>>> The feature in parameter exists as a different instance in the
>>> array.
>>> The feature in parameter is referring to 'myvariable' and in the array,
>>> at the expected index, I see a feature also referring to 'myvariable',
>>> but with a different instance id.
>>
>>> here is the stack trace:
>>
>>> Daemon Thread [Thread-3] (Suspended)
>>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>>> CDORevisionImpl.getValue(CDOFeature) line: 492
>>> CDOPropertyGetter.get(Object) line: 40
>>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line:
>>> 46
>>
>> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>>
>>> Map, SessionImplementor) line: 271
>>
>> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>>
>>> Map, SessionImplementor) line: 3673
>>
>> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>>
>>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>>> line: 267
>>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>>> line: 181
>>
>> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>>
>>> String, Object, EventSource, boolean) line: 107
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>>
>>> line: 187
>>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>>
>>> line: 33
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>>
>>> line: 172
>>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line:
>>> 27
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>>
>>> line: 70 SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>>> SessionImpl.save(String, Object) line: 523
>>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>>> line: 180
>>> CommitTransactionIndication.indicating(ExtendedDataInputStre am) line:
>>> 109
>>
>> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>>
>>> BufferOutputStream) line: 46
>>> CommitTransactionIndication(Signal).runSync() line: 143
>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>>> ThreadPoolExecutor$Worker.run() line: not available
>>> Thread.run() line: not available
>>
>>> Martin Taal wrote:
>>>> Hi Eric, I have this fix also locally but currently part of the
>>>> testcases fail because of something related to EDataType resolving. I
>>>> can't say if the issue you report is related.
>>>>
>>>> Regarding the code below, do you mean that the feature (passed as a
>>>> parameter) exists in the allFeatures but as a different instance
>>>> (that's why == fails)? Or is the feature completely wrong and does
>>>> not even belong to the cdoclass in question?
>>>>
>>>> What is the stacktrace, or where is getFeatureID called from?
>>>>
>>>> gr. Martin
>>>>
>>>> Eric wrote:
>>>>> Hi Martin, Eike,
>>>>>
>>>>> I have a problem when looking for features with the latest version
>>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>>>> about multiple inheritence in CDO and the fix was to add the
>>>>> following code to CDOClassImpl.java(version 1.35):
>>>>>
>>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>>> = getAllFeatures(); while (index < features.length) { if
>>>>> (features[index] == feature) <------- Need to be same object! {
>>>>> return index; }
>>>>>
>>>>> ++index; } }
>>>>>
>>>>> return -1; }
>>>>>
>>>>> As you can see, in order to find the right feature, it needs to be
>>>>> contained in the allFeatures[] array. When debugging my code,
>>>>> we've noticed that the feature I was looking for wasn't in the
>>>>> array, so probably Teneo did a copy of the features... Is it
>>>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>>>
>>>>> Thanks, Eric
>>>>
>>>>
>>
>>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119612 is a reply to message #119599] Tue, 22 April 2008 21:11 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric,
The CDOPropertyGetter is used to integrate hibernate with CDO. During the application startup the
hibernate mapping is created and for each feature a property getter/setter is created.
When persisting and reading an object from the db the propertygetter/setter is used by hibernate to
get the data from/to the cdo object.

Eike, where does the revision get the cdoclass instance from? The hibernate layer reads the
cdopackages from the db, so maybe it misses some initialization code somewhere?
Also when writePackages is done then the hibernatelayer will not replace cdoclasses/cdopackages if
the underlying ecore has not changed. So maybe the client does writepackages with a new
cdopackage/cdoclass instance and the hibernate layer does not replace it, while it should.

gr. Martin

Eric wrote:
> Hi Martin, Eike,
>
> I have verified what Eike said:
>
> 1) all the elements of allFeatures are indeed present in the features list.
> 2) The CDOFeature argument is coming from the private member of
> CDOPropertyHandler.
>
> I am not that familiar with CDO as I am learning on the go, but here is
> what I see:
>
> The CDOPropertyGetter has a tuplizer that contains a cdoClass and in
> this cdoClass, I can see the CDOFeature I am looking for (both in the
> allFeatures[] array and the features list). But, the revision in the
> following piece of code (from CDOPropertyGetter.java):
> public Object get(Object target) throws HibernateException
> {
> InternalCDORevision revision = (InternalCDORevision)target;
> return revision.getValue(getCDOFeature());
> }
>
> that revision also contains a cdoClass, but this cdoClass does not
> contain the feature I am looking for. I can see an equivalent feature
> (same attributes, but different instance, just like a copy), but their
> pointers differ. And obviously, the cdoClass from the revision is not
> the same instance as the one in the tuplizer.
>
> I don't know if all of this clarifies my problem, but I'd like to get
> some light on the role of the cdoClass in tuplizer versus the one in the
> revision...
>
> Thanks!
> Eric
>
> Eike Stepper wrote:
>> Hey guys,
>>
>> I can confirm that the allFeatures array, once initialized, should
>> contain pointers to the already existing features of all the
>> superTypes plus the own features.
>>
>> And I can't remember of any place where CDO copies instance data of a
>> CDOFeature. All the CDOModelElements are considered immutable and
>> appropriate for testing reference equality (just like with
>> EModelElements).
>>
>> Eric, could you please verify
>> 1) that the element of the allFeatures array occurs somewhere in the
>> features List (possibly in a superType)
>> 2) where your argument to getFeatureID() comes from (did Martin ask
>> this already?)
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Hi Martin, Eric,
>>>
>>> Tonight I will have the chance to look at the code and clarify the
>>> expected semantics of the allFeatures array. I can't recall it w/o
>>> code ;-(
>>>
>>> Eric, did I apply the patch (multi-inheritance) correctly from your
>>> point of view?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Martin,
>>>
>>>> The feature in parameter exists as a different instance in the
>>>> array.
>>>> The feature in parameter is referring to 'myvariable' and in the array,
>>>> at the expected index, I see a feature also referring to 'myvariable',
>>>> but with a different instance id.
>>>
>>>> here is the stack trace:
>>>
>>>> Daemon Thread [Thread-3] (Suspended)
>>>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>>>> CDORevisionImpl.getValue(CDOFeature) line: 492
>>>> CDOPropertyGetter.get(Object) line: 40
>>>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor)
>>>> line: 46
>>>
>>> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>>>
>>>> Map, SessionImplementor) line: 271
>>>
>>> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>>>
>>>> Map, SessionImplementor) line: 3673
>>>
>>> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>>>
>>>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>>>> line: 267
>>>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>>>> line: 181
>>>
>>> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>>>
>>>> String, Object, EventSource, boolean) line: 107
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>>>
>>>> line: 187
>>>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>>>
>>>> line: 33
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>>>
>>>> line: 172
>>>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt)
>>>> line: 27
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>>>
>>>> line: 70 SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>>>> SessionImpl.save(String, Object) line: 523
>>>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>>>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>>>> line: 180
>>>> CommitTransactionIndication.indicating(ExtendedDataInputStre am)
>>>> line: 109
>>>
>>> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>>>
>>>> BufferOutputStream) line: 46
>>>> CommitTransactionIndication(Signal).runSync() line: 143
>>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not
>>>> available ThreadPoolExecutor$Worker.runTask(Runnable) line:
>>>> not available ThreadPoolExecutor$Worker.run() line: not
>>>> available Thread.run() line: not available
>>>
>>>> Martin Taal wrote:
>>>>> Hi Eric, I have this fix also locally but currently part of the
>>>>> testcases fail because of something related to EDataType resolving. I
>>>>> can't say if the issue you report is related.
>>>>>
>>>>> Regarding the code below, do you mean that the feature (passed as a
>>>>> parameter) exists in the allFeatures but as a different instance
>>>>> (that's why == fails)? Or is the feature completely wrong and does
>>>>> not even belong to the cdoclass in question?
>>>>>
>>>>> What is the stacktrace, or where is getFeatureID called from?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Eric wrote:
>>>>>> Hi Martin, Eike,
>>>>>>
>>>>>> I have a problem when looking for features with the latest version
>>>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>>>>> about multiple inheritence in CDO and the fix was to add the
>>>>>> following code to CDOClassImpl.java(version 1.35):
>>>>>>
>>>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>>>> = getAllFeatures(); while (index < features.length) { if
>>>>>> (features[index] == feature) <------- Need to be same object! {
>>>>>> return index; }
>>>>>>
>>>>>> ++index; } }
>>>>>>
>>>>>> return -1; }
>>>>>>
>>>>>> As you can see, in order to find the right feature, it needs to be
>>>>>> contained in the allFeatures[] array. When debugging my code,
>>>>>> we've noticed that the feature I was looking for wasn't in the
>>>>>> array, so probably Teneo did a copy of the features... Is it
>>>>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>>>>
>>>>>> Thanks, Eric
>>>>>
>>>>>
>>>
>>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119653 is a reply to message #119612] Wed, 23 April 2008 07:39 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Guys,

One idea popped into my mind although it's pretty unprobable: If there's
something wrong with synchronization it could eventually happen that some
state gets duplicated. But that would hardly be reproduceable.

Martin, I have currently no code at hand, but I seem to recall that
packages have to be initialized/post-processed after they have been
received from a client (resolving forward references and so). This can
only happen after all of several packages have arrived. It's also possible
that I changed this mechanism to lazy getters. In this case these getters
should not be called before all packages have arrived from the client.
I'll have to clarify this tonight...

Eric, is it possible that you send us a small test case that reproduces
the problem, ideally attached to a Bugzilla?

Cheers
/Eike


Martin Taal wrote:

> Hi Eric,
> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
application startup the
> hibernate mapping is created and for each feature a property getter/setter
is created.
> When persisting and reading an object from the db the propertygetter/setter
is used by hibernate to
> get the data from/to the cdo object.

> Eike, where does the revision get the cdoclass instance from? The hibernate
layer reads the
> cdopackages from the db, so maybe it misses some initialization code
somewhere?
> Also when writePackages is done then the hibernatelayer will not replace
cdoclasses/cdopackages if
> the underlying ecore has not changed. So maybe the client does writepackages
with a new
> cdopackage/cdoclass instance and the hibernate layer does not replace it,
while it should.

> gr. Martin


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119703 is a reply to message #119653] Wed, 23 April 2008 12:54 Go to previous messageGo to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi guys,

I'm trying to create a small test case and I decided to use your
model (model1) for my test case. My test case failed with the following
error (and I tried to run CDO's Hibernate test suite and I get the same
error for many testcases)

org.eclipse.net4j.util.transaction.TransactionException: Could not
determine type for: null, at table: address, for columns:
[org.hibernate.mapping.Column(preferred)]
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
at
org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)


What am I doing wrong here?

Eike Stepper wrote:
> Guys,
>
> One idea popped into my mind although it's pretty unprobable: If there's
> something wrong with synchronization it could eventually happen that
> some state gets duplicated. But that would hardly be reproduceable.
>
> Martin, I have currently no code at hand, but I seem to recall that
> packages have to be initialized/post-processed after they have been
> received from a client (resolving forward references and so). This can
> only happen after all of several packages have arrived. It's also
> possible that I changed this mechanism to lazy getters. In this case
> these getters should not be called before all packages have arrived from
> the client. I'll have to clarify this tonight...
>
> Eric, is it possible that you send us a small test case that reproduces
> the problem, ideally attached to a Bugzilla?
>
> Cheers
> /Eike
>
>
> Martin Taal wrote:
>
>> Hi Eric,
>> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
> application startup the
>> hibernate mapping is created and for each feature a property
>> getter/setter
> is created.
>> When persisting and reading an object from the db the
>> propertygetter/setter
> is used by hibernate to
>> get the data from/to the cdo object.
>
>> Eike, where does the revision get the cdoclass instance from? The
>> hibernate
> layer reads the
>> cdopackages from the db, so maybe it misses some initialization code
> somewhere?
>> Also when writePackages is done then the hibernatelayer will not replace
> cdoclasses/cdopackages if
>> the underlying ecore has not changed. So maybe the client does
>> writepackages
> with a new
>> cdopackage/cdoclass instance and the hibernate layer does not replace it,
> while it should.
>
>> gr. Martin
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119716 is a reply to message #119703] Wed, 23 April 2008 13:04 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Eric,

I think Martin told me about this issue recently. Seems to be a
regression. We have not identified the root cause yet, but efforts
ongoing...

Martin, do you have new insights?

Cheers
/Eike

Eric wrote:

> Hi guys,

> I'm trying to create a small test case and I decided to use your
> model (model1) for my test case. My test case failed with the following
> error (and I tried to run CDO's Hibernate test suite and I get the same
> error for many testcases)

> org.eclipse.net4j.util.transaction.TransactionException: Could not
> determine type for: null, at table: address, for columns:
> [org.hibernate.mapping.Column(preferred)]
> at
>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
> at
>
org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:164)
> at org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
> at junit.framework.TestCase.runBare(TestCase.java:130)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:120)
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
> at junit.framework.TestSuite.run(TestSuite.java:225)
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
> at junit.framework.TestSuite.run(TestSuite.java:225)
> at
>
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
> at
>
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)


> What am I doing wrong here?

> Eike Stepper wrote:
>> Guys,
>>
>> One idea popped into my mind although it's pretty unprobable: If there's
>> something wrong with synchronization it could eventually happen that
>> some state gets duplicated. But that would hardly be reproduceable.
>>
>> Martin, I have currently no code at hand, but I seem to recall that
>> packages have to be initialized/post-processed after they have been
>> received from a client (resolving forward references and so). This can
>> only happen after all of several packages have arrived. It's also
>> possible that I changed this mechanism to lazy getters. In this case
>> these getters should not be called before all packages have arrived from
>> the client. I'll have to clarify this tonight...
>>
>> Eric, is it possible that you send us a small test case that reproduces
>> the problem, ideally attached to a Bugzilla?
>>
>> Cheers
>> /Eike
>>
>>
>> Martin Taal wrote:
>>
>>> Hi Eric,
>>> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
>> application startup the
>>> hibernate mapping is created and for each feature a property
>>> getter/setter
>> is created.
>>> When persisting and reading an object from the db the
>>> propertygetter/setter
>> is used by hibernate to
>>> get the data from/to the cdo object.
>>
>>> Eike, where does the revision get the cdoclass instance from? The
>>> hibernate
>> layer reads the
>>> cdopackages from the db, so maybe it misses some initialization code
>> somewhere?
>>> Also when writePackages is done then the hibernatelayer will not replace
>> cdoclasses/cdopackages if
>>> the underlying ecore has not changed. So maybe the client does
>>> writepackages
>> with a new
>>> cdopackage/cdoclass instance and the hibernate layer does not replace it,
>> while it should.
>>
>>> gr. Martin
>>
>>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119729 is a reply to message #119716] Wed, 23 April 2008 13:17 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric, Eike,
I will check this issue out later today, so no new insights I am afraid.

gr. Martin

Eike Stepper wrote:
> Hi Eric,
>
> I think Martin told me about this issue recently. Seems to be a
> regression. We have not identified the root cause yet, but efforts
> ongoing...
>
> Martin, do you have new insights?
>
> Cheers
> /Eike
>
> Eric wrote:
>
>> Hi guys,
>
>> I'm trying to create a small test case and I decided to use your
>> model (model1) for my test case. My test case failed with the
>> following error (and I tried to run CDO's Hibernate test suite and I
>> get the same error for many testcases)
>
>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>> determine type for: null, at table: address, for columns:
>> [org.hibernate.mapping.Column(preferred)]
>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>
>> at
> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>> at
>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:120)
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>
>> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>
>
>
>> What am I doing wrong here?
>
>> Eike Stepper wrote:
>>> Guys,
>>>
>>> One idea popped into my mind although it's pretty unprobable: If
>>> there's something wrong with synchronization it could eventually
>>> happen that some state gets duplicated. But that would hardly be
>>> reproduceable.
>>>
>>> Martin, I have currently no code at hand, but I seem to recall that
>>> packages have to be initialized/post-processed after they have been
>>> received from a client (resolving forward references and so). This
>>> can only happen after all of several packages have arrived. It's also
>>> possible that I changed this mechanism to lazy getters. In this case
>>> these getters should not be called before all packages have arrived
>>> from the client. I'll have to clarify this tonight...
>>>
>>> Eric, is it possible that you send us a small test case that
>>> reproduces the problem, ideally attached to a Bugzilla?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Martin Taal wrote:
>>>
>>>> Hi Eric,
>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>> During the
>>> application startup the
>>>> hibernate mapping is created and for each feature a property
>>>> getter/setter
>>> is created.
>>>> When persisting and reading an object from the db the
>>>> propertygetter/setter
>>> is used by hibernate to
>>>> get the data from/to the cdo object.
>>>
>>>> Eike, where does the revision get the cdoclass instance from? The
>>>> hibernate
>>> layer reads the
>>>> cdopackages from the db, so maybe it misses some initialization code
>>> somewhere?
>>>> Also when writePackages is done then the hibernatelayer will not
>>>> replace
>>> cdoclasses/cdopackages if
>>>> the underlying ecore has not changed. So maybe the client does
>>>> writepackages
>>> with a new
>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>> replace it,
>>> while it should.
>>>
>>>> gr. Martin
>>>
>>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119742 is a reply to message #119729] Wed, 23 April 2008 13:28 Go to previous messageGo to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
I've entered a bug in bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=228403 with 2 projects in
attachment. One contains my simple model and the other one contains a
test case. Just run AllTest and you should see the error. Let me know
if there is anything I can do. Meanwhile I'll keep trying to figure out
what is going on.

Martin Taal wrote:
> Hi Eric, Eike,
> I will check this issue out later today, so no new insights I am afraid.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I think Martin told me about this issue recently. Seems to be a
>> regression. We have not identified the root cause yet, but efforts
>> ongoing...
>>
>> Martin, do you have new insights?
>>
>> Cheers
>> /Eike
>>
>> Eric wrote:
>>
>>> Hi guys,
>>
>>> I'm trying to create a small test case and I decided to use your
>>> model (model1) for my test case. My test case failed with the
>>> following error (and I tried to run CDO's Hibernate test suite and I
>>> get the same error for many testcases)
>>
>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>> determine type for: null, at table: address, for columns:
>>> [org.hibernate.mapping.Column(preferred)]
>>> at
>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>
>>> at
>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at
>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>> at junit.framework.TestResult.run(TestResult.java:109)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>
>>
>>
>>> What am I doing wrong here?
>>
>>> Eike Stepper wrote:
>>>> Guys,
>>>>
>>>> One idea popped into my mind although it's pretty unprobable: If
>>>> there's something wrong with synchronization it could eventually
>>>> happen that some state gets duplicated. But that would hardly be
>>>> reproduceable.
>>>>
>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>> packages have to be initialized/post-processed after they have been
>>>> received from a client (resolving forward references and so). This
>>>> can only happen after all of several packages have arrived. It's
>>>> also possible that I changed this mechanism to lazy getters. In this
>>>> case these getters should not be called before all packages have
>>>> arrived from the client. I'll have to clarify this tonight...
>>>>
>>>> Eric, is it possible that you send us a small test case that
>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Eric,
>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>> During the
>>>> application startup the
>>>>> hibernate mapping is created and for each feature a property
>>>>> getter/setter
>>>> is created.
>>>>> When persisting and reading an object from the db the
>>>>> propertygetter/setter
>>>> is used by hibernate to
>>>>> get the data from/to the cdo object.
>>>>
>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>> hibernate
>>>> layer reads the
>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>> somewhere?
>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>> replace
>>>> cdoclasses/cdopackages if
>>>>> the underlying ecore has not changed. So maybe the client does
>>>>> writepackages
>>>> with a new
>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>> replace it,
>>>> while it should.
>>>>
>>>>> gr. Martin
>>>>
>>>>
>>
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119755 is a reply to message #119729] Wed, 23 April 2008 14:49 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi martin,

From a quick look I saw that htere's a suspicious method in HibernateStoreReader:

org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage, CDOPackage)

Could that be related?

Cheers
/Eike



Martin Taal schrieb:
> Hi Eric, Eike,
> I will check this issue out later today, so no new insights I am afraid.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I think Martin told me about this issue recently. Seems to be a
>> regression. We have not identified the root cause yet, but efforts
>> ongoing...
>>
>> Martin, do you have new insights?
>>
>> Cheers
>> /Eike
>>
>> Eric wrote:
>>
>>> Hi guys,
>>
>>> I'm trying to create a small test case and I decided to use your
>>> model (model1) for my test case. My test case failed with the
>>> following error (and I tried to run CDO's Hibernate test suite and I
>>> get the same error for many testcases)
>>
>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>> determine type for: null, at table: address, for columns:
>>> [org.hibernate.mapping.Column(preferred)]
>>> at
>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>
>>> at
>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at
>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>> at junit.framework.TestResult.run(TestResult.java:109)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>
>>
>>
>>> What am I doing wrong here?
>>
>>> Eike Stepper wrote:
>>>> Guys,
>>>>
>>>> One idea popped into my mind although it's pretty unprobable: If
>>>> there's something wrong with synchronization it could eventually
>>>> happen that some state gets duplicated. But that would hardly be
>>>> reproduceable.
>>>>
>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>> packages have to be initialized/post-processed after they have been
>>>> received from a client (resolving forward references and so). This
>>>> can only happen after all of several packages have arrived. It's
>>>> also possible that I changed this mechanism to lazy getters. In this
>>>> case these getters should not be called before all packages have
>>>> arrived from the client. I'll have to clarify this tonight...
>>>>
>>>> Eric, is it possible that you send us a small test case that
>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Eric,
>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>> During the
>>>> application startup the
>>>>> hibernate mapping is created and for each feature a property
>>>>> getter/setter
>>>> is created.
>>>>> When persisting and reading an object from the db the
>>>>> propertygetter/setter
>>>> is used by hibernate to
>>>>> get the data from/to the cdo object.
>>>>
>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>> hibernate
>>>> layer reads the
>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>> somewhere?
>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>> replace
>>>> cdoclasses/cdopackages if
>>>>> the underlying ecore has not changed. So maybe the client does
>>>>> writepackages
>>>> with a new
>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>> replace it,
>>>> while it should.
>>>>
>>>>> gr. Martin
>>>>
>>>>
>>
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119771 is a reply to message #119755] Wed, 23 April 2008 14:58 Go to previous messageGo to next message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
I saw it too yesterday and I did put a breakpoint at the beginning of
the method, but it looks like this method is never called in my test
case. :(

While debugging, I've noticed that the CDOFeature for argument of
CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
EPackages... Since the cdoClass of that same revision does not contain
the CDOFeature in argument, can you tell me where I can find code
populating the list of features of that cdoClass, so I can check where
those features are coming from?

Thanks,
Eric

Eike Stepper wrote:
> Hi martin,
>
> From a quick look I saw that htere's a suspicious method in
> HibernateStoreReader:
>
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
> CDOPackage)
>
> Could that be related?
>
> Cheers
> /Eike
>
>
>
> Martin Taal schrieb:
>> Hi Eric, Eike,
>> I will check this issue out later today, so no new insights I am afraid.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Hi Eric,
>>>
>>> I think Martin told me about this issue recently. Seems to be a
>>> regression. We have not identified the root cause yet, but efforts
>>> ongoing...
>>>
>>> Martin, do you have new insights?
>>>
>>> Cheers
>>> /Eike
>>>
>>> Eric wrote:
>>>
>>>> Hi guys,
>>>
>>>> I'm trying to create a small test case and I decided to use your
>>>> model (model1) for my test case. My test case failed with the
>>>> following error (and I tried to run CDO's Hibernate test suite and I
>>>> get the same error for many testcases)
>>>
>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>> determine type for: null, at table: address, for columns:
>>>> [org.hibernate.mapping.Column(preferred)]
>>>> at
>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>
>>>> at
>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>> at
>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>
>>>
>>>
>>>> What am I doing wrong here?
>>>
>>>> Eike Stepper wrote:
>>>>> Guys,
>>>>>
>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>> there's something wrong with synchronization it could eventually
>>>>> happen that some state gets duplicated. But that would hardly be
>>>>> reproduceable.
>>>>>
>>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>>> packages have to be initialized/post-processed after they have been
>>>>> received from a client (resolving forward references and so). This
>>>>> can only happen after all of several packages have arrived. It's
>>>>> also possible that I changed this mechanism to lazy getters. In
>>>>> this case these getters should not be called before all packages
>>>>> have arrived from the client. I'll have to clarify this tonight...
>>>>>
>>>>> Eric, is it possible that you send us a small test case that
>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>
>>>>>> Hi Eric,
>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>> During the
>>>>> application startup the
>>>>>> hibernate mapping is created and for each feature a property
>>>>>> getter/setter
>>>>> is created.
>>>>>> When persisting and reading an object from the db the
>>>>>> propertygetter/setter
>>>>> is used by hibernate to
>>>>>> get the data from/to the cdo object.
>>>>>
>>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>>> hibernate
>>>>> layer reads the
>>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>>> somewhere?
>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>> replace
>>>>> cdoclasses/cdopackages if
>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>> writepackages
>>>>> with a new
>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>> replace it,
>>>>> while it should.
>>>>>
>>>>>> gr. Martin
>>>>>
>>>>>
>>>
>>
>>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119781 is a reply to message #119771] Wed, 23 April 2008 15:42 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
I should have thought about this method. It is called when the PackageManagerresolve(CDOPackage
cdoPackage) method is called. The system will then read the cdopackage from the db. The cdopackage
from the db is then copied into the cdopackage passed through the readPackage method. So the
cdoclasses/cdofeatures are copied into this cdopackage.

I am not sure (doubt) that this is the correct way.

Because of the above copy action the following happens:
The HibernatePackageHandler has instances of the CDOPackage and CDOClasses etc.
These are used to initialize the PropertyGetters etc.
However the cdo PackageManager has another instance of the CDOPackage in-memory.
Afaik these are then used to set the model data in the cdorevision

So the solution would probably that the hibernate initialization code should use the packagemanager
instead of the packagehandler. Then it does not matter that the database packagehandler has its own
set of cdopackages.

Eike, what do you think? Would this work?

gr. Martin

Eric wrote:
> I saw it too yesterday and I did put a breakpoint at the beginning of
> the method, but it looks like this method is never called in my test
> case. :(
>
> While debugging, I've noticed that the CDOFeature for argument of
> CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
> EPackages... Since the cdoClass of that same revision does not contain
> the CDOFeature in argument, can you tell me where I can find code
> populating the list of features of that cdoClass, so I can check where
> those features are coming from?
>
> Thanks,
> Eric
>
> Eike Stepper wrote:
>> Hi martin,
>>
>> From a quick look I saw that htere's a suspicious method in
>> HibernateStoreReader:
>>
>>
>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
>> CDOPackage)
>>
>> Could that be related?
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Martin Taal schrieb:
>>> Hi Eric, Eike,
>>> I will check this issue out later today, so no new insights I am afraid.
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Hi Eric,
>>>>
>>>> I think Martin told me about this issue recently. Seems to be a
>>>> regression. We have not identified the root cause yet, but efforts
>>>> ongoing...
>>>>
>>>> Martin, do you have new insights?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> Eric wrote:
>>>>
>>>>> Hi guys,
>>>>
>>>>> I'm trying to create a small test case and I decided to use your
>>>>> model (model1) for my test case. My test case failed with the
>>>>> following error (and I tried to run CDO's Hibernate test suite and
>>>>> I get the same error for many testcases)
>>>>
>>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>>> determine type for: null, at table: address, for columns:
>>>>> [org.hibernate.mapping.Column(preferred)]
>>>>> at
>>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>>
>>>>> at
>>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>>> at
>>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>>
>>>>
>>>>
>>>>> What am I doing wrong here?
>>>>
>>>>> Eike Stepper wrote:
>>>>>> Guys,
>>>>>>
>>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>>> there's something wrong with synchronization it could eventually
>>>>>> happen that some state gets duplicated. But that would hardly be
>>>>>> reproduceable.
>>>>>>
>>>>>> Martin, I have currently no code at hand, but I seem to recall
>>>>>> that packages have to be initialized/post-processed after they
>>>>>> have been received from a client (resolving forward references and
>>>>>> so). This can only happen after all of several packages have
>>>>>> arrived. It's also possible that I changed this mechanism to lazy
>>>>>> getters. In this case these getters should not be called before
>>>>>> all packages have arrived from the client. I'll have to clarify
>>>>>> this tonight...
>>>>>>
>>>>>> Eric, is it possible that you send us a small test case that
>>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>
>>>>>>> Hi Eric,
>>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>>> During the
>>>>>> application startup the
>>>>>>> hibernate mapping is created and for each feature a property
>>>>>>> getter/setter
>>>>>> is created.
>>>>>>> When persisting and reading an object from the db the
>>>>>>> propertygetter/setter
>>>>>> is used by hibernate to
>>>>>>> get the data from/to the cdo object.
>>>>>>
>>>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>>>> hibernate
>>>>>> layer reads the
>>>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>>>> somewhere?
>>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>>> replace
>>>>>> cdoclasses/cdopackages if
>>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>>> writepackages
>>>>>> with a new
>>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>>> replace it,
>>>>>> while it should.
>>>>>>
>>>>>>> gr. Martin
>>>>>>
>>>>>>
>>>>
>>>
>>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119794 is a reply to message #119781] Wed, 23 April 2008 15:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Martin Taal schrieb:
> I should have thought about this method. It is called when the
> PackageManagerresolve(CDOPackage cdoPackage) method is called. The
> system will then read the cdopackage from the db. The cdopackage from
> the db is then copied into the cdopackage passed through the readPackage
> method. So the cdoclasses/cdofeatures are copied into this cdopackage.
>
> I am not sure (doubt) that this is the correct way.
>
> Because of the above copy action the following happens:
> The HibernatePackageHandler has instances of the CDOPackage and
> CDOClasses etc.
> These are used to initialize the PropertyGetters etc.
> However the cdo PackageManager has another instance of the CDOPackage
> in-memory.
> Afaik these are then used to set the model data in the cdorevision
>
> So the solution would probably that the hibernate initialization code
> should use the packagemanager instead of the packagehandler. Then it
> does not matter that the database packagehandler has its own set of
> cdopackages.
>
> Eike, what do you think? Would this work?

Sounds reasonable at least ;-)
Within the CDO system at most one instance of any CDOModelElement should be used. Pointers to them are passed around very frequently and even used in pointer comparisons. If the HibernateStore needs to use copies internally that should be ok as long as these are back-translated whenever needed in the rest of the CDO framework.

Cheers
/Eike


>
> gr. Martin
>
> Eric wrote:
>> I saw it too yesterday and I did put a breakpoint at the beginning of
>> the method, but it looks like this method is never called in my test
>> case. :(
>>
>> While debugging, I've noticed that the CDOFeature for argument of
>> CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
>> EPackages... Since the cdoClass of that same revision does not
>> contain the CDOFeature in argument, can you tell me where I can find
>> code populating the list of features of that cdoClass, so I can check
>> where those features are coming from?
>>
>> Thanks,
>> Eric
>>
>> Eike Stepper wrote:
>>> Hi martin,
>>>
>>> From a quick look I saw that htere's a suspicious method in
>>> HibernateStoreReader:
>>>
>>>
>>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
>>> CDOPackage)
>>>
>>> Could that be related?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> Martin Taal schrieb:
>>>> Hi Eric, Eike,
>>>> I will check this issue out later today, so no new insights I am
>>>> afraid.
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I think Martin told me about this issue recently. Seems to be a
>>>>> regression. We have not identified the root cause yet, but efforts
>>>>> ongoing...
>>>>>
>>>>> Martin, do you have new insights?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi guys,
>>>>>
>>>>>> I'm trying to create a small test case and I decided to use
>>>>>> your model (model1) for my test case. My test case failed with
>>>>>> the following error (and I tried to run CDO's Hibernate test suite
>>>>>> and I get the same error for many testcases)
>>>>>
>>>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>>>> determine type for: null, at table: address, for columns:
>>>>>> [org.hibernate.mapping.Column(preferred)]
>>>>>> at
>>>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>>>
>>>>>> at
>>>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>>>
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>>>> at
>>>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>>>>
>>>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>>>
>>>>>
>>>>>
>>>>>> What am I doing wrong here?
>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Guys,
>>>>>>>
>>>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>>>> there's something wrong with synchronization it could eventually
>>>>>>> happen that some state gets duplicated. But that would hardly be
>>>>>>> reproduceable.
>>>>>>>
>>>>>>> Martin, I have currently no code at hand, but I seem to recall
>>>>>>> that packages have to be initialized/post-processed after they
>>>>>>> have been received from a client (resolving forward references
>>>>>>> and so). This can only happen after all of several packages have
>>>>>>> arrived. It's also possible that I changed this mechanism to lazy
>>>>>>> getters. In this case these getters should not be called before
>>>>>>> all packages have arrived from the client. I'll have to clarify
>>>>>>> this tonight...
>>>>>>>
>>>>>>> Eric, is it possible that you send us a small test case that
>>>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>>
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>
>>>>>>>> Hi Eric,
>>>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>>>> During the
>>>>>>> application startup the
>>>>>>>> hibernate mapping is created and for each feature a property
>>>>>>>> getter/setter
>>>>>>> is created.
>>>>>>>> When persisting and reading an object from the db the
>>>>>>>> propertygetter/setter
>>>>>>> is used by hibernate to
>>>>>>>> get the data from/to the cdo object.
>>>>>>>
>>>>>>>> Eike, where does the revision get the cdoclass instance from?
>>>>>>>> The hibernate
>>>>>>> layer reads the
>>>>>>>> cdopackages from the db, so maybe it misses some initialization
>>>>>>>> code
>>>>>>> somewhere?
>>>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>>>> replace
>>>>>>> cdoclasses/cdopackages if
>>>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>>>> writepackages
>>>>>>> with a new
>>>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>>>> replace it,
>>>>>>> while it should.
>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #119830 is a reply to message #119742] Thu, 24 April 2008 07:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Short update:

Martin and I worked together on this issue yesterday evening and we seem
to be on the track. It relates somehow to the Hibernate SessionFactory
being recreated for new packages (on commit and after server restart). We
keep you informed via the Bugzilla...

Cheers
/Eike


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617874 is a reply to message #119496] Tue, 22 April 2008 13:48 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric,
I have this fix also locally but currently part of the testcases fail because of something related
to EDataType resolving. I can't say if the issue you report is related.

Regarding the code below, do you mean that the feature (passed as a parameter) exists in the
allFeatures but as a different instance (that's why == fails)? Or is the feature completely wrong
and does not even belong to the cdoclass in question?

What is the stacktrace, or where is getFeatureID called from?

gr. Martin

Eric wrote:
> Hi Martin, Eike,
>
> I have a problem when looking for features with the latest version of
> CDO (from CVS). Me and Simon reported a bug a few days ago about
> multiple inheritence in CDO and the fix was to add the following code to
> CDOClassImpl.java(version 1.35):
>
> public int getFeatureID(CDOFeature feature)
> {
> int index = feature.getFeatureIndex();
> if (index != -1)
> {
> CDOFeature[] features = getAllFeatures();
> while (index < features.length)
> {
> if (features[index] == feature) <------- Need to be same object!
> {
> return index;
> }
>
> ++index;
> }
> }
>
> return -1;
> }
>
> As you can see, in order to find the right feature, it needs to be
> contained in the allFeatures[] array. When debugging my code, we've
> noticed that the feature I was looking for wasn't in the array, so
> probably Teneo did a copy of the features... Is it possible that Teneo
> might not be up to date with this CDO fix yet?
>
> Thanks,
> Eric


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617875 is a reply to message #119522] Tue, 22 April 2008 13:56 Go to previous message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi Martin,

The feature in parameter exists as a different instance in the array.
The feature in parameter is referring to 'myvariable' and in the array,
at the expected index, I see a feature also referring to 'myvariable',
but with a different instance id.

here is the stack trace:

Daemon Thread [Thread-3] (Suspended)
CDOClassImpl.getFeatureID(CDOFeature) line: 111
CDORevisionImpl.getValue(CDOFeature) line: 492
CDOPropertyGetter.get(Object) line: 40
CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line: 46
CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
Map, SessionImplementor) line: 271
SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
Map, SessionImplementor) line: 3673
DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
line: 267
DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
Serializable, EntityPersister, boolean, Object, EventSource, boolean)
line: 181
DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
String, Object, EventSource, boolean) line: 107
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
line: 187
DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
line: 33
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
line: 172
DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line: 27
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
line: 70
SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
SessionImpl.save(String, Object) line: 523
HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
line: 180
CommitTransactionIndication.indicating(ExtendedDataInputStre am) line: 109
CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
BufferOutputStream) line: 46
CommitTransactionIndication(Signal).runSync() line: 143
ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
ThreadPoolExecutor$Worker.run() line: not available
Thread.run() line: not available

Martin Taal wrote:
> Hi Eric, I have this fix also locally but currently part of the
> testcases fail because of something related to EDataType resolving. I
> can't say if the issue you report is related.
>
> Regarding the code below, do you mean that the feature (passed as a
> parameter) exists in the allFeatures but as a different instance
> (that's why == fails)? Or is the feature completely wrong and does
> not even belong to the cdoclass in question?
>
> What is the stacktrace, or where is getFeatureID called from?
>
> gr. Martin
>
> Eric wrote:
>> Hi Martin, Eike,
>>
>> I have a problem when looking for features with the latest version
>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>> about multiple inheritence in CDO and the fix was to add the
>> following code to CDOClassImpl.java(version 1.35):
>>
>> public int getFeatureID(CDOFeature feature) { int index =
>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>> = getAllFeatures(); while (index < features.length) { if
>> (features[index] == feature) <------- Need to be same object! {
>> return index; }
>>
>> ++index; } }
>>
>> return -1; }
>>
>> As you can see, in order to find the right feature, it needs to be
>> contained in the allFeatures[] array. When debugging my code,
>> we've noticed that the feature I was looking for wasn't in the
>> array, so probably Teneo did a copy of the features... Is it
>> possible that Teneo might not be up to date with this CDO fix yet?
>>
>> Thanks, Eric
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617877 is a reply to message #119538] Tue, 22 April 2008 15:01 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Martin, Eric,

Tonight I will have the chance to look at the code and clarify the
expected semantics of the allFeatures array. I can't recall it w/o code ;-(

Eric, did I apply the patch (multi-inheritance) correctly from your point
of view?

Cheers
/Eike


Eric wrote:

> Hi Martin,

> The feature in parameter exists as a different instance in the array.
> The feature in parameter is referring to 'myvariable' and in the array,
> at the expected index, I see a feature also referring to 'myvariable',
> but with a different instance id.

> here is the stack trace:

> Daemon Thread [Thread-3] (Suspended)
> CDOClassImpl.getFeatureID(CDOFeature) line: 111
> CDORevisionImpl.getValue(CDOFeature) line: 492
> CDOPropertyGetter.get(Object) line: 40
> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line: 46
>
CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
> Map, SessionImplementor) line: 271
>
SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
> Map, SessionImplementor) line: 3673
>
DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
> line: 267
> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
> line: 181
>
DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
> String, Object, EventSource, boolean) line: 107
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
> line: 187
> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
> line: 33
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
> line: 172
> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line: 27
>
DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
> line: 70
> SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
> SessionImpl.save(String, Object) line: 523
> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
> line: 180
> CommitTransactionIndication.indicating(ExtendedDataInputStre am) line: 109
>
CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
> BufferOutputStream) line: 46
> CommitTransactionIndication(Signal).runSync() line: 143
> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
> ThreadPoolExecutor$Worker.run() line: not available
> Thread.run() line: not available

> Martin Taal wrote:
>> Hi Eric, I have this fix also locally but currently part of the
>> testcases fail because of something related to EDataType resolving. I
>> can't say if the issue you report is related.
>>
>> Regarding the code below, do you mean that the feature (passed as a
>> parameter) exists in the allFeatures but as a different instance
>> (that's why == fails)? Or is the feature completely wrong and does
>> not even belong to the cdoclass in question?
>>
>> What is the stacktrace, or where is getFeatureID called from?
>>
>> gr. Martin
>>
>> Eric wrote:
>>> Hi Martin, Eike,
>>>
>>> I have a problem when looking for features with the latest version
>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>> about multiple inheritence in CDO and the fix was to add the
>>> following code to CDOClassImpl.java(version 1.35):
>>>
>>> public int getFeatureID(CDOFeature feature) { int index =
>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>> = getAllFeatures(); while (index < features.length) { if
>>> (features[index] == feature) <------- Need to be same object! {
>>> return index; }
>>>
>>> ++index; } }
>>>
>>> return -1; }
>>>
>>> As you can see, in order to find the right feature, it needs to be
>>> contained in the allFeatures[] array. When debugging my code,
>>> we've noticed that the feature I was looking for wasn't in the
>>> array, so probably Teneo did a copy of the features... Is it
>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>
>>> Thanks, Eric
>>
>>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617879 is a reply to message #119560] Tue, 22 April 2008 18:27 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hey guys,

I can confirm that the allFeatures array, once initialized, should contain pointers to the already existing features of all the superTypes plus the own features.

And I can't remember of any place where CDO copies instance data of a CDOFeature. All the CDOModelElements are considered immutable and appropriate for testing reference equality (just like with EModelElements).

Eric, could you please verify
1) that the element of the allFeatures array occurs somewhere in the features List (possibly in a superType)
2) where your argument to getFeatureID() comes from (did Martin ask this already?)

Cheers
/Eike


Eike Stepper schrieb:
> Hi Martin, Eric,
>
> Tonight I will have the chance to look at the code and clarify the
> expected semantics of the allFeatures array. I can't recall it w/o code ;-(
>
> Eric, did I apply the patch (multi-inheritance) correctly from your
> point of view?
>
> Cheers
> /Eike
>
>
> Eric wrote:
>
>> Hi Martin,
>
>> The feature in parameter exists as a different instance in the array.
>> The feature in parameter is referring to 'myvariable' and in the array,
>> at the expected index, I see a feature also referring to 'myvariable',
>> but with a different instance id.
>
>> here is the stack trace:
>
>> Daemon Thread [Thread-3] (Suspended)
>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>> CDORevisionImpl.getValue(CDOFeature) line: 492
>> CDOPropertyGetter.get(Object) line: 40
>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor)
>> line: 46
>>
> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>
>> Map, SessionImplementor) line: 271
>>
> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>
>> Map, SessionImplementor) line: 3673
>>
> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>
>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>> line: 267
>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>
>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>> line: 181
>>
> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>
>> String, Object, EventSource, boolean) line: 107
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>
>> line: 187
>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>
>> line: 33
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>
>> line: 172
>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt)
>> line: 27
>>
> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>
>> line: 70
>> SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>> SessionImpl.save(String, Object) line: 523
>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>> line: 180
>> CommitTransactionIndication.indicating(ExtendedDataInputStre am)
>> line: 109
>>
> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>
>> BufferOutputStream) line: 46
>> CommitTransactionIndication(Signal).runSync() line: 143
>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>> ThreadPoolExecutor$Worker.run() line: not available
>> Thread.run() line: not available
>
>> Martin Taal wrote:
>>> Hi Eric, I have this fix also locally but currently part of the
>>> testcases fail because of something related to EDataType resolving. I
>>> can't say if the issue you report is related.
>>>
>>> Regarding the code below, do you mean that the feature (passed as a
>>> parameter) exists in the allFeatures but as a different instance
>>> (that's why == fails)? Or is the feature completely wrong and does
>>> not even belong to the cdoclass in question?
>>>
>>> What is the stacktrace, or where is getFeatureID called from?
>>>
>>> gr. Martin
>>>
>>> Eric wrote:
>>>> Hi Martin, Eike,
>>>>
>>>> I have a problem when looking for features with the latest version
>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago about
>>>> multiple inheritence in CDO and the fix was to add the following
>>>> code to CDOClassImpl.java(version 1.35):
>>>>
>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>> = getAllFeatures(); while (index < features.length) { if
>>>> (features[index] == feature) <------- Need to be same object! {
>>>> return index; }
>>>>
>>>> ++index; } }
>>>>
>>>> return -1; }
>>>>
>>>> As you can see, in order to find the right feature, it needs to be
>>>> contained in the allFeatures[] array. When debugging my code, we've
>>>> noticed that the feature I was looking for wasn't in the array, so
>>>> probably Teneo did a copy of the features... Is it possible that
>>>> Teneo might not be up to date with this CDO fix yet?
>>>>
>>>> Thanks, Eric
>>>
>>>
>
>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617880 is a reply to message #119586] Tue, 22 April 2008 19:48 Go to previous message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi Martin, Eike,

I have verified what Eike said:

1) all the elements of allFeatures are indeed present in the features list.
2) The CDOFeature argument is coming from the private member of
CDOPropertyHandler.

I am not that familiar with CDO as I am learning on the go, but here is
what I see:

The CDOPropertyGetter has a tuplizer that contains a cdoClass and in
this cdoClass, I can see the CDOFeature I am looking for (both in the
allFeatures[] array and the features list). But, the revision in the
following piece of code (from CDOPropertyGetter.java):
public Object get(Object target) throws HibernateException
{
InternalCDORevision revision = (InternalCDORevision)target;
return revision.getValue(getCDOFeature());
}

that revision also contains a cdoClass, but this cdoClass does not
contain the feature I am looking for. I can see an equivalent feature
(same attributes, but different instance, just like a copy), but their
pointers differ. And obviously, the cdoClass from the revision is not
the same instance as the one in the tuplizer.

I don't know if all of this clarifies my problem, but I'd like to get
some light on the role of the cdoClass in tuplizer versus the one in the
revision...

Thanks!
Eric

Eike Stepper wrote:
> Hey guys,
>
> I can confirm that the allFeatures array, once initialized, should
> contain pointers to the already existing features of all the superTypes
> plus the own features.
>
> And I can't remember of any place where CDO copies instance data of a
> CDOFeature. All the CDOModelElements are considered immutable and
> appropriate for testing reference equality (just like with EModelElements).
>
> Eric, could you please verify
> 1) that the element of the allFeatures array occurs somewhere in the
> features List (possibly in a superType)
> 2) where your argument to getFeatureID() comes from (did Martin ask this
> already?)
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>> Hi Martin, Eric,
>>
>> Tonight I will have the chance to look at the code and clarify the
>> expected semantics of the allFeatures array. I can't recall it w/o
>> code ;-(
>>
>> Eric, did I apply the patch (multi-inheritance) correctly from your
>> point of view?
>>
>> Cheers
>> /Eike
>>
>>
>> Eric wrote:
>>
>>> Hi Martin,
>>
>>> The feature in parameter exists as a different instance in the
>>> array.
>>> The feature in parameter is referring to 'myvariable' and in the array,
>>> at the expected index, I see a feature also referring to 'myvariable',
>>> but with a different instance id.
>>
>>> here is the stack trace:
>>
>>> Daemon Thread [Thread-3] (Suspended)
>>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>>> CDORevisionImpl.getValue(CDOFeature) line: 492
>>> CDOPropertyGetter.get(Object) line: 40
>>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor) line:
>>> 46
>>
>> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>>
>>> Map, SessionImplementor) line: 271
>>
>> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>>
>>> Map, SessionImplementor) line: 3673
>>
>> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>>
>>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>>> line: 267
>>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>>> line: 181
>>
>> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>>
>>> String, Object, EventSource, boolean) line: 107
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>>
>>> line: 187
>>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>>
>>> line: 33
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>>
>>> line: 172
>>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt) line:
>>> 27
>>
>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>>
>>> line: 70 SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>>> SessionImpl.save(String, Object) line: 523
>>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>>> line: 180
>>> CommitTransactionIndication.indicating(ExtendedDataInputStre am) line:
>>> 109
>>
>> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>>
>>> BufferOutputStream) line: 46
>>> CommitTransactionIndication(Signal).runSync() line: 143
>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
>>> ThreadPoolExecutor$Worker.run() line: not available
>>> Thread.run() line: not available
>>
>>> Martin Taal wrote:
>>>> Hi Eric, I have this fix also locally but currently part of the
>>>> testcases fail because of something related to EDataType resolving. I
>>>> can't say if the issue you report is related.
>>>>
>>>> Regarding the code below, do you mean that the feature (passed as a
>>>> parameter) exists in the allFeatures but as a different instance
>>>> (that's why == fails)? Or is the feature completely wrong and does
>>>> not even belong to the cdoclass in question?
>>>>
>>>> What is the stacktrace, or where is getFeatureID called from?
>>>>
>>>> gr. Martin
>>>>
>>>> Eric wrote:
>>>>> Hi Martin, Eike,
>>>>>
>>>>> I have a problem when looking for features with the latest version
>>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>>>> about multiple inheritence in CDO and the fix was to add the
>>>>> following code to CDOClassImpl.java(version 1.35):
>>>>>
>>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>>> = getAllFeatures(); while (index < features.length) { if
>>>>> (features[index] == feature) <------- Need to be same object! {
>>>>> return index; }
>>>>>
>>>>> ++index; } }
>>>>>
>>>>> return -1; }
>>>>>
>>>>> As you can see, in order to find the right feature, it needs to be
>>>>> contained in the allFeatures[] array. When debugging my code,
>>>>> we've noticed that the feature I was looking for wasn't in the
>>>>> array, so probably Teneo did a copy of the features... Is it
>>>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>>>
>>>>> Thanks, Eric
>>>>
>>>>
>>
>>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617881 is a reply to message #119599] Tue, 22 April 2008 21:11 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric,
The CDOPropertyGetter is used to integrate hibernate with CDO. During the application startup the
hibernate mapping is created and for each feature a property getter/setter is created.
When persisting and reading an object from the db the propertygetter/setter is used by hibernate to
get the data from/to the cdo object.

Eike, where does the revision get the cdoclass instance from? The hibernate layer reads the
cdopackages from the db, so maybe it misses some initialization code somewhere?
Also when writePackages is done then the hibernatelayer will not replace cdoclasses/cdopackages if
the underlying ecore has not changed. So maybe the client does writepackages with a new
cdopackage/cdoclass instance and the hibernate layer does not replace it, while it should.

gr. Martin

Eric wrote:
> Hi Martin, Eike,
>
> I have verified what Eike said:
>
> 1) all the elements of allFeatures are indeed present in the features list.
> 2) The CDOFeature argument is coming from the private member of
> CDOPropertyHandler.
>
> I am not that familiar with CDO as I am learning on the go, but here is
> what I see:
>
> The CDOPropertyGetter has a tuplizer that contains a cdoClass and in
> this cdoClass, I can see the CDOFeature I am looking for (both in the
> allFeatures[] array and the features list). But, the revision in the
> following piece of code (from CDOPropertyGetter.java):
> public Object get(Object target) throws HibernateException
> {
> InternalCDORevision revision = (InternalCDORevision)target;
> return revision.getValue(getCDOFeature());
> }
>
> that revision also contains a cdoClass, but this cdoClass does not
> contain the feature I am looking for. I can see an equivalent feature
> (same attributes, but different instance, just like a copy), but their
> pointers differ. And obviously, the cdoClass from the revision is not
> the same instance as the one in the tuplizer.
>
> I don't know if all of this clarifies my problem, but I'd like to get
> some light on the role of the cdoClass in tuplizer versus the one in the
> revision...
>
> Thanks!
> Eric
>
> Eike Stepper wrote:
>> Hey guys,
>>
>> I can confirm that the allFeatures array, once initialized, should
>> contain pointers to the already existing features of all the
>> superTypes plus the own features.
>>
>> And I can't remember of any place where CDO copies instance data of a
>> CDOFeature. All the CDOModelElements are considered immutable and
>> appropriate for testing reference equality (just like with
>> EModelElements).
>>
>> Eric, could you please verify
>> 1) that the element of the allFeatures array occurs somewhere in the
>> features List (possibly in a superType)
>> 2) where your argument to getFeatureID() comes from (did Martin ask
>> this already?)
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Hi Martin, Eric,
>>>
>>> Tonight I will have the chance to look at the code and clarify the
>>> expected semantics of the allFeatures array. I can't recall it w/o
>>> code ;-(
>>>
>>> Eric, did I apply the patch (multi-inheritance) correctly from your
>>> point of view?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eric wrote:
>>>
>>>> Hi Martin,
>>>
>>>> The feature in parameter exists as a different instance in the
>>>> array.
>>>> The feature in parameter is referring to 'myvariable' and in the array,
>>>> at the expected index, I see a feature also referring to 'myvariable',
>>>> but with a different instance id.
>>>
>>>> here is the stack trace:
>>>
>>>> Daemon Thread [Thread-3] (Suspended)
>>>> CDOClassImpl.getFeatureID(CDOFeature) line: 111
>>>> CDORevisionImpl.getValue(CDOFeature) line: 492
>>>> CDOPropertyGetter.get(Object) line: 40
>>>> CDOPropertyGetter.getForInsert(Object, Map, SessionImplementor)
>>>> line: 46
>>>
>>> CDORevisionTuplizer(AbstractEntityTuplizer).getPropertyValue sToInsert(Object,
>>>
>>>> Map, SessionImplementor) line: 271
>>>
>>> SingleTableEntityPersister(AbstractEntityPersister).getPrope rtyValuesToInsert(Object,
>>>
>>>> Map, SessionImplementor) line: 3673
>>>
>>> DefaultSaveEventListener(AbstractSaveEventListener).performS aveOrReplicate(Object,
>>>
>>>> EntityKey, EntityPersister, boolean, Object, EventSource, boolean)
>>>> line: 267
>>>> DefaultSaveEventListener(AbstractSaveEventListener).performS ave(Object,
>>>> Serializable, EntityPersister, boolean, Object, EventSource, boolean)
>>>> line: 181
>>>
>>> DefaultSaveEventListener(AbstractSaveEventListener).saveWith GeneratedId(Object,
>>>
>>>> String, Object, EventSource, boolean) line: 107
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).s aveWithGeneratedOrRequestedId(SaveOrUpdateEvent)
>>>
>>>> line: 187
>>>> DefaultSaveEventListener.saveWithGeneratedOrRequestedId(Save OrUpdateEvent)
>>>>
>>>> line: 33
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).e ntityIsTransient(SaveOrUpdateEvent)
>>>
>>>> line: 172
>>>> DefaultSaveEventListener.performSaveOrUpdate(SaveOrUpdateEve nt)
>>>> line: 27
>>>
>>> DefaultSaveEventListener(DefaultSaveOrUpdateEventListener).o nSaveOrUpdate(SaveOrUpdateEvent)
>>>
>>>> line: 70 SessionImpl.fireSave(SaveOrUpdateEvent) line: 535
>>>> SessionImpl.save(String, Object) line: 523
>>>> HibernateStoreWriter.commit(IStoreWriter$CommitContext) line: 64
>>>> Transaction.commit(CDOPackage[], CDORevision[], CDORevisionDelta[])
>>>> line: 180
>>>> CommitTransactionIndication.indicating(ExtendedDataInputStre am)
>>>> line: 109
>>>
>>> CommitTransactionIndication(IndicationWithResponse).execute( BufferInputStream,
>>>
>>>> BufferOutputStream) line: 46
>>>> CommitTransactionIndication(Signal).runSync() line: 143
>>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: not
>>>> available ThreadPoolExecutor$Worker.runTask(Runnable) line:
>>>> not available ThreadPoolExecutor$Worker.run() line: not
>>>> available Thread.run() line: not available
>>>
>>>> Martin Taal wrote:
>>>>> Hi Eric, I have this fix also locally but currently part of the
>>>>> testcases fail because of something related to EDataType resolving. I
>>>>> can't say if the issue you report is related.
>>>>>
>>>>> Regarding the code below, do you mean that the feature (passed as a
>>>>> parameter) exists in the allFeatures but as a different instance
>>>>> (that's why == fails)? Or is the feature completely wrong and does
>>>>> not even belong to the cdoclass in question?
>>>>>
>>>>> What is the stacktrace, or where is getFeatureID called from?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Eric wrote:
>>>>>> Hi Martin, Eike,
>>>>>>
>>>>>> I have a problem when looking for features with the latest version
>>>>>> of CDO (from CVS). Me and Simon reported a bug a few days ago
>>>>>> about multiple inheritence in CDO and the fix was to add the
>>>>>> following code to CDOClassImpl.java(version 1.35):
>>>>>>
>>>>>> public int getFeatureID(CDOFeature feature) { int index =
>>>>>> feature.getFeatureIndex(); if (index != -1) { CDOFeature[] features
>>>>>> = getAllFeatures(); while (index < features.length) { if
>>>>>> (features[index] == feature) <------- Need to be same object! {
>>>>>> return index; }
>>>>>>
>>>>>> ++index; } }
>>>>>>
>>>>>> return -1; }
>>>>>>
>>>>>> As you can see, in order to find the right feature, it needs to be
>>>>>> contained in the allFeatures[] array. When debugging my code,
>>>>>> we've noticed that the feature I was looking for wasn't in the
>>>>>> array, so probably Teneo did a copy of the features... Is it
>>>>>> possible that Teneo might not be up to date with this CDO fix yet?
>>>>>>
>>>>>> Thanks, Eric
>>>>>
>>>>>
>>>
>>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617884 is a reply to message #119612] Wed, 23 April 2008 07:39 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Guys,

One idea popped into my mind although it's pretty unprobable: If there's
something wrong with synchronization it could eventually happen that some
state gets duplicated. But that would hardly be reproduceable.

Martin, I have currently no code at hand, but I seem to recall that
packages have to be initialized/post-processed after they have been
received from a client (resolving forward references and so). This can
only happen after all of several packages have arrived. It's also possible
that I changed this mechanism to lazy getters. In this case these getters
should not be called before all packages have arrived from the client.
I'll have to clarify this tonight...

Eric, is it possible that you send us a small test case that reproduces
the problem, ideally attached to a Bugzilla?

Cheers
/Eike


Martin Taal wrote:

> Hi Eric,
> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
application startup the
> hibernate mapping is created and for each feature a property getter/setter
is created.
> When persisting and reading an object from the db the propertygetter/setter
is used by hibernate to
> get the data from/to the cdo object.

> Eike, where does the revision get the cdoclass instance from? The hibernate
layer reads the
> cdopackages from the db, so maybe it misses some initialization code
somewhere?
> Also when writePackages is done then the hibernatelayer will not replace
cdoclasses/cdopackages if
> the underlying ecore has not changed. So maybe the client does writepackages
with a new
> cdopackage/cdoclass instance and the hibernate layer does not replace it,
while it should.

> gr. Martin


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617888 is a reply to message #119653] Wed, 23 April 2008 12:54 Go to previous message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
Hi guys,

I'm trying to create a small test case and I decided to use your
model (model1) for my test case. My test case failed with the following
error (and I tried to run CDO's Hibernate test suite and I get the same
error for many testcases)

org.eclipse.net4j.util.transaction.TransactionException: Could not
determine type for: null, at table: address, for columns:
[org.hibernate.mapping.Column(preferred)]
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
at
org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)


What am I doing wrong here?

Eike Stepper wrote:
> Guys,
>
> One idea popped into my mind although it's pretty unprobable: If there's
> something wrong with synchronization it could eventually happen that
> some state gets duplicated. But that would hardly be reproduceable.
>
> Martin, I have currently no code at hand, but I seem to recall that
> packages have to be initialized/post-processed after they have been
> received from a client (resolving forward references and so). This can
> only happen after all of several packages have arrived. It's also
> possible that I changed this mechanism to lazy getters. In this case
> these getters should not be called before all packages have arrived from
> the client. I'll have to clarify this tonight...
>
> Eric, is it possible that you send us a small test case that reproduces
> the problem, ideally attached to a Bugzilla?
>
> Cheers
> /Eike
>
>
> Martin Taal wrote:
>
>> Hi Eric,
>> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
> application startup the
>> hibernate mapping is created and for each feature a property
>> getter/setter
> is created.
>> When persisting and reading an object from the db the
>> propertygetter/setter
> is used by hibernate to
>> get the data from/to the cdo object.
>
>> Eike, where does the revision get the cdoclass instance from? The
>> hibernate
> layer reads the
>> cdopackages from the db, so maybe it misses some initialization code
> somewhere?
>> Also when writePackages is done then the hibernatelayer will not replace
> cdoclasses/cdopackages if
>> the underlying ecore has not changed. So maybe the client does
>> writepackages
> with a new
>> cdopackage/cdoclass instance and the hibernate layer does not replace it,
> while it should.
>
>> gr. Martin
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617889 is a reply to message #119703] Wed, 23 April 2008 13:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi Eric,

I think Martin told me about this issue recently. Seems to be a
regression. We have not identified the root cause yet, but efforts
ongoing...

Martin, do you have new insights?

Cheers
/Eike

Eric wrote:

> Hi guys,

> I'm trying to create a small test case and I decided to use your
> model (model1) for my test case. My test case failed with the following
> error (and I tried to run CDO's Hibernate test suite and I get the same
> error for many testcases)

> org.eclipse.net4j.util.transaction.TransactionException: Could not
> determine type for: null, at table: address, for columns:
> [org.hibernate.mapping.Column(preferred)]
> at
>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
> at
>
org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:164)
> at org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
> at junit.framework.TestCase.runBare(TestCase.java:130)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:120)
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
> at junit.framework.TestSuite.run(TestSuite.java:225)
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
> at junit.framework.TestSuite.run(TestSuite.java:225)
> at
>
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
> at
>
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
> at
>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)


> What am I doing wrong here?

> Eike Stepper wrote:
>> Guys,
>>
>> One idea popped into my mind although it's pretty unprobable: If there's
>> something wrong with synchronization it could eventually happen that
>> some state gets duplicated. But that would hardly be reproduceable.
>>
>> Martin, I have currently no code at hand, but I seem to recall that
>> packages have to be initialized/post-processed after they have been
>> received from a client (resolving forward references and so). This can
>> only happen after all of several packages have arrived. It's also
>> possible that I changed this mechanism to lazy getters. In this case
>> these getters should not be called before all packages have arrived from
>> the client. I'll have to clarify this tonight...
>>
>> Eric, is it possible that you send us a small test case that reproduces
>> the problem, ideally attached to a Bugzilla?
>>
>> Cheers
>> /Eike
>>
>>
>> Martin Taal wrote:
>>
>>> Hi Eric,
>>> The CDOPropertyGetter is used to integrate hibernate with CDO. During the
>> application startup the
>>> hibernate mapping is created and for each feature a property
>>> getter/setter
>> is created.
>>> When persisting and reading an object from the db the
>>> propertygetter/setter
>> is used by hibernate to
>>> get the data from/to the cdo object.
>>
>>> Eike, where does the revision get the cdoclass instance from? The
>>> hibernate
>> layer reads the
>>> cdopackages from the db, so maybe it misses some initialization code
>> somewhere?
>>> Also when writePackages is done then the hibernatelayer will not replace
>> cdoclasses/cdopackages if
>>> the underlying ecore has not changed. So maybe the client does
>>> writepackages
>> with a new
>>> cdopackage/cdoclass instance and the hibernate layer does not replace it,
>> while it should.
>>
>>> gr. Martin
>>
>>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617890 is a reply to message #119716] Wed, 23 April 2008 13:17 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eric, Eike,
I will check this issue out later today, so no new insights I am afraid.

gr. Martin

Eike Stepper wrote:
> Hi Eric,
>
> I think Martin told me about this issue recently. Seems to be a
> regression. We have not identified the root cause yet, but efforts
> ongoing...
>
> Martin, do you have new insights?
>
> Cheers
> /Eike
>
> Eric wrote:
>
>> Hi guys,
>
>> I'm trying to create a small test case and I decided to use your
>> model (model1) for my test case. My test case failed with the
>> following error (and I tried to run CDO's Hibernate test suite and I
>> get the same error for many testcases)
>
>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>> determine type for: null, at table: address, for columns:
>> [org.hibernate.mapping.Column(preferred)]
>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>
>> at
> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>> at
>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:120)
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>> at junit.framework.TestSuite.run(TestSuite.java:225)
>> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>
>> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>
>> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>
>
>
>> What am I doing wrong here?
>
>> Eike Stepper wrote:
>>> Guys,
>>>
>>> One idea popped into my mind although it's pretty unprobable: If
>>> there's something wrong with synchronization it could eventually
>>> happen that some state gets duplicated. But that would hardly be
>>> reproduceable.
>>>
>>> Martin, I have currently no code at hand, but I seem to recall that
>>> packages have to be initialized/post-processed after they have been
>>> received from a client (resolving forward references and so). This
>>> can only happen after all of several packages have arrived. It's also
>>> possible that I changed this mechanism to lazy getters. In this case
>>> these getters should not be called before all packages have arrived
>>> from the client. I'll have to clarify this tonight...
>>>
>>> Eric, is it possible that you send us a small test case that
>>> reproduces the problem, ideally attached to a Bugzilla?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Martin Taal wrote:
>>>
>>>> Hi Eric,
>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>> During the
>>> application startup the
>>>> hibernate mapping is created and for each feature a property
>>>> getter/setter
>>> is created.
>>>> When persisting and reading an object from the db the
>>>> propertygetter/setter
>>> is used by hibernate to
>>>> get the data from/to the cdo object.
>>>
>>>> Eike, where does the revision get the cdoclass instance from? The
>>>> hibernate
>>> layer reads the
>>>> cdopackages from the db, so maybe it misses some initialization code
>>> somewhere?
>>>> Also when writePackages is done then the hibernatelayer will not
>>>> replace
>>> cdoclasses/cdopackages if
>>>> the underlying ecore has not changed. So maybe the client does
>>>> writepackages
>>> with a new
>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>> replace it,
>>> while it should.
>>>
>>>> gr. Martin
>>>
>>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617891 is a reply to message #119729] Wed, 23 April 2008 13:28 Go to previous message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
I've entered a bug in bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=228403 with 2 projects in
attachment. One contains my simple model and the other one contains a
test case. Just run AllTest and you should see the error. Let me know
if there is anything I can do. Meanwhile I'll keep trying to figure out
what is going on.

Martin Taal wrote:
> Hi Eric, Eike,
> I will check this issue out later today, so no new insights I am afraid.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I think Martin told me about this issue recently. Seems to be a
>> regression. We have not identified the root cause yet, but efforts
>> ongoing...
>>
>> Martin, do you have new insights?
>>
>> Cheers
>> /Eike
>>
>> Eric wrote:
>>
>>> Hi guys,
>>
>>> I'm trying to create a small test case and I decided to use your
>>> model (model1) for my test case. My test case failed with the
>>> following error (and I tried to run CDO's Hibernate test suite and I
>>> get the same error for many testcases)
>>
>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>> determine type for: null, at table: address, for columns:
>>> [org.hibernate.mapping.Column(preferred)]
>>> at
>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>
>>> at
>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at
>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>> at junit.framework.TestResult.run(TestResult.java:109)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>
>>
>>
>>> What am I doing wrong here?
>>
>>> Eike Stepper wrote:
>>>> Guys,
>>>>
>>>> One idea popped into my mind although it's pretty unprobable: If
>>>> there's something wrong with synchronization it could eventually
>>>> happen that some state gets duplicated. But that would hardly be
>>>> reproduceable.
>>>>
>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>> packages have to be initialized/post-processed after they have been
>>>> received from a client (resolving forward references and so). This
>>>> can only happen after all of several packages have arrived. It's
>>>> also possible that I changed this mechanism to lazy getters. In this
>>>> case these getters should not be called before all packages have
>>>> arrived from the client. I'll have to clarify this tonight...
>>>>
>>>> Eric, is it possible that you send us a small test case that
>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Eric,
>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>> During the
>>>> application startup the
>>>>> hibernate mapping is created and for each feature a property
>>>>> getter/setter
>>>> is created.
>>>>> When persisting and reading an object from the db the
>>>>> propertygetter/setter
>>>> is used by hibernate to
>>>>> get the data from/to the cdo object.
>>>>
>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>> hibernate
>>>> layer reads the
>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>> somewhere?
>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>> replace
>>>> cdoclasses/cdopackages if
>>>>> the underlying ecore has not changed. So maybe the client does
>>>>> writepackages
>>>> with a new
>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>> replace it,
>>>> while it should.
>>>>
>>>>> gr. Martin
>>>>
>>>>
>>
>
>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617892 is a reply to message #119729] Wed, 23 April 2008 14:49 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Hi martin,

From a quick look I saw that htere's a suspicious method in HibernateStoreReader:

org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage, CDOPackage)

Could that be related?

Cheers
/Eike



Martin Taal schrieb:
> Hi Eric, Eike,
> I will check this issue out later today, so no new insights I am afraid.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Eric,
>>
>> I think Martin told me about this issue recently. Seems to be a
>> regression. We have not identified the root cause yet, but efforts
>> ongoing...
>>
>> Martin, do you have new insights?
>>
>> Cheers
>> /Eike
>>
>> Eric wrote:
>>
>>> Hi guys,
>>
>>> I'm trying to create a small test case and I decided to use your
>>> model (model1) for my test case. My test case failed with the
>>> following error (and I tried to run CDO's Hibernate test suite and I
>>> get the same error for many testcases)
>>
>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>> determine type for: null, at table: address, for columns:
>>> [org.hibernate.mapping.Column(preferred)]
>>> at
>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>
>>> at
>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at
>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>> at junit.framework.TestResult.run(TestResult.java:109)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>
>>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>
>>
>>
>>> What am I doing wrong here?
>>
>>> Eike Stepper wrote:
>>>> Guys,
>>>>
>>>> One idea popped into my mind although it's pretty unprobable: If
>>>> there's something wrong with synchronization it could eventually
>>>> happen that some state gets duplicated. But that would hardly be
>>>> reproduceable.
>>>>
>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>> packages have to be initialized/post-processed after they have been
>>>> received from a client (resolving forward references and so). This
>>>> can only happen after all of several packages have arrived. It's
>>>> also possible that I changed this mechanism to lazy getters. In this
>>>> case these getters should not be called before all packages have
>>>> arrived from the client. I'll have to clarify this tonight...
>>>>
>>>> Eric, is it possible that you send us a small test case that
>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>
>>>>> Hi Eric,
>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>> During the
>>>> application startup the
>>>>> hibernate mapping is created and for each feature a property
>>>>> getter/setter
>>>> is created.
>>>>> When persisting and reading an object from the db the
>>>>> propertygetter/setter
>>>> is used by hibernate to
>>>>> get the data from/to the cdo object.
>>>>
>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>> hibernate
>>>> layer reads the
>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>> somewhere?
>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>> replace
>>>> cdoclasses/cdopackages if
>>>>> the underlying ecore has not changed. So maybe the client does
>>>>> writepackages
>>>> with a new
>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>> replace it,
>>>> while it should.
>>>>
>>>>> gr. Martin
>>>>
>>>>
>>
>
>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617893 is a reply to message #119755] Wed, 23 April 2008 14:58 Go to previous message
Eric is currently offline EricFriend
Messages: 40
Registered: July 2009
Member
I saw it too yesterday and I did put a breakpoint at the beginning of
the method, but it looks like this method is never called in my test
case. :(

While debugging, I've noticed that the CDOFeature for argument of
CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
EPackages... Since the cdoClass of that same revision does not contain
the CDOFeature in argument, can you tell me where I can find code
populating the list of features of that cdoClass, so I can check where
those features are coming from?

Thanks,
Eric

Eike Stepper wrote:
> Hi martin,
>
> From a quick look I saw that htere's a suspicious method in
> HibernateStoreReader:
>
> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
> CDOPackage)
>
> Could that be related?
>
> Cheers
> /Eike
>
>
>
> Martin Taal schrieb:
>> Hi Eric, Eike,
>> I will check this issue out later today, so no new insights I am afraid.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Hi Eric,
>>>
>>> I think Martin told me about this issue recently. Seems to be a
>>> regression. We have not identified the root cause yet, but efforts
>>> ongoing...
>>>
>>> Martin, do you have new insights?
>>>
>>> Cheers
>>> /Eike
>>>
>>> Eric wrote:
>>>
>>>> Hi guys,
>>>
>>>> I'm trying to create a small test case and I decided to use your
>>>> model (model1) for my test case. My test case failed with the
>>>> following error (and I tried to run CDO's Hibernate test suite and I
>>>> get the same error for many testcases)
>>>
>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>> determine type for: null, at table: address, for columns:
>>>> [org.hibernate.mapping.Column(preferred)]
>>>> at
>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>
>>>> at
>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>> at
>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>
>>>> at
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>
>>>
>>>
>>>> What am I doing wrong here?
>>>
>>>> Eike Stepper wrote:
>>>>> Guys,
>>>>>
>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>> there's something wrong with synchronization it could eventually
>>>>> happen that some state gets duplicated. But that would hardly be
>>>>> reproduceable.
>>>>>
>>>>> Martin, I have currently no code at hand, but I seem to recall that
>>>>> packages have to be initialized/post-processed after they have been
>>>>> received from a client (resolving forward references and so). This
>>>>> can only happen after all of several packages have arrived. It's
>>>>> also possible that I changed this mechanism to lazy getters. In
>>>>> this case these getters should not be called before all packages
>>>>> have arrived from the client. I'll have to clarify this tonight...
>>>>>
>>>>> Eric, is it possible that you send us a small test case that
>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>
>>>>>> Hi Eric,
>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>> During the
>>>>> application startup the
>>>>>> hibernate mapping is created and for each feature a property
>>>>>> getter/setter
>>>>> is created.
>>>>>> When persisting and reading an object from the db the
>>>>>> propertygetter/setter
>>>>> is used by hibernate to
>>>>>> get the data from/to the cdo object.
>>>>>
>>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>>> hibernate
>>>>> layer reads the
>>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>>> somewhere?
>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>> replace
>>>>> cdoclasses/cdopackages if
>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>> writepackages
>>>>> with a new
>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>> replace it,
>>>>> while it should.
>>>>>
>>>>>> gr. Martin
>>>>>
>>>>>
>>>
>>
>>
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617894 is a reply to message #119771] Wed, 23 April 2008 15:42 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
I should have thought about this method. It is called when the PackageManagerresolve(CDOPackage
cdoPackage) method is called. The system will then read the cdopackage from the db. The cdopackage
from the db is then copied into the cdopackage passed through the readPackage method. So the
cdoclasses/cdofeatures are copied into this cdopackage.

I am not sure (doubt) that this is the correct way.

Because of the above copy action the following happens:
The HibernatePackageHandler has instances of the CDOPackage and CDOClasses etc.
These are used to initialize the PropertyGetters etc.
However the cdo PackageManager has another instance of the CDOPackage in-memory.
Afaik these are then used to set the model data in the cdorevision

So the solution would probably that the hibernate initialization code should use the packagemanager
instead of the packagehandler. Then it does not matter that the database packagehandler has its own
set of cdopackages.

Eike, what do you think? Would this work?

gr. Martin

Eric wrote:
> I saw it too yesterday and I did put a breakpoint at the beginning of
> the method, but it looks like this method is never called in my test
> case. :(
>
> While debugging, I've noticed that the CDOFeature for argument of
> CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
> EPackages... Since the cdoClass of that same revision does not contain
> the CDOFeature in argument, can you tell me where I can find code
> populating the list of features of that cdoClass, so I can check where
> those features are coming from?
>
> Thanks,
> Eric
>
> Eike Stepper wrote:
>> Hi martin,
>>
>> From a quick look I saw that htere's a suspicious method in
>> HibernateStoreReader:
>>
>>
>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
>> CDOPackage)
>>
>> Could that be related?
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Martin Taal schrieb:
>>> Hi Eric, Eike,
>>> I will check this issue out later today, so no new insights I am afraid.
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Hi Eric,
>>>>
>>>> I think Martin told me about this issue recently. Seems to be a
>>>> regression. We have not identified the root cause yet, but efforts
>>>> ongoing...
>>>>
>>>> Martin, do you have new insights?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> Eric wrote:
>>>>
>>>>> Hi guys,
>>>>
>>>>> I'm trying to create a small test case and I decided to use your
>>>>> model (model1) for my test case. My test case failed with the
>>>>> following error (and I tried to run CDO's Hibernate test suite and
>>>>> I get the same error for many testcases)
>>>>
>>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>>> determine type for: null, at table: address, for columns:
>>>>> [org.hibernate.mapping.Column(preferred)]
>>>>> at
>>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>>
>>>>> at
>>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>>> at
>>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>>
>>>>> at
>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>>
>>>>
>>>>
>>>>> What am I doing wrong here?
>>>>
>>>>> Eike Stepper wrote:
>>>>>> Guys,
>>>>>>
>>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>>> there's something wrong with synchronization it could eventually
>>>>>> happen that some state gets duplicated. But that would hardly be
>>>>>> reproduceable.
>>>>>>
>>>>>> Martin, I have currently no code at hand, but I seem to recall
>>>>>> that packages have to be initialized/post-processed after they
>>>>>> have been received from a client (resolving forward references and
>>>>>> so). This can only happen after all of several packages have
>>>>>> arrived. It's also possible that I changed this mechanism to lazy
>>>>>> getters. In this case these getters should not be called before
>>>>>> all packages have arrived from the client. I'll have to clarify
>>>>>> this tonight...
>>>>>>
>>>>>> Eric, is it possible that you send us a small test case that
>>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>
>>>>>>> Hi Eric,
>>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>>> During the
>>>>>> application startup the
>>>>>>> hibernate mapping is created and for each feature a property
>>>>>>> getter/setter
>>>>>> is created.
>>>>>>> When persisting and reading an object from the db the
>>>>>>> propertygetter/setter
>>>>>> is used by hibernate to
>>>>>>> get the data from/to the cdo object.
>>>>>>
>>>>>>> Eike, where does the revision get the cdoclass instance from? The
>>>>>>> hibernate
>>>>>> layer reads the
>>>>>>> cdopackages from the db, so maybe it misses some initialization code
>>>>>> somewhere?
>>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>>> replace
>>>>>> cdoclasses/cdopackages if
>>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>>> writepackages
>>>>>> with a new
>>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>>> replace it,
>>>>>> while it should.
>>>>>>
>>>>>>> gr. Martin
>>>>>>
>>>>>>
>>>>
>>>
>>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617895 is a reply to message #119781] Wed, 23 April 2008 15:50 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Martin Taal schrieb:
> I should have thought about this method. It is called when the
> PackageManagerresolve(CDOPackage cdoPackage) method is called. The
> system will then read the cdopackage from the db. The cdopackage from
> the db is then copied into the cdopackage passed through the readPackage
> method. So the cdoclasses/cdofeatures are copied into this cdopackage.
>
> I am not sure (doubt) that this is the correct way.
>
> Because of the above copy action the following happens:
> The HibernatePackageHandler has instances of the CDOPackage and
> CDOClasses etc.
> These are used to initialize the PropertyGetters etc.
> However the cdo PackageManager has another instance of the CDOPackage
> in-memory.
> Afaik these are then used to set the model data in the cdorevision
>
> So the solution would probably that the hibernate initialization code
> should use the packagemanager instead of the packagehandler. Then it
> does not matter that the database packagehandler has its own set of
> cdopackages.
>
> Eike, what do you think? Would this work?

Sounds reasonable at least ;-)
Within the CDO system at most one instance of any CDOModelElement should be used. Pointers to them are passed around very frequently and even used in pointer comparisons. If the HibernateStore needs to use copies internally that should be ok as long as these are back-translated whenever needed in the rest of the CDO framework.

Cheers
/Eike


>
> gr. Martin
>
> Eric wrote:
>> I saw it too yesterday and I did put a breakpoint at the beginning of
>> the method, but it looks like this method is never called in my test
>> case. :(
>>
>> While debugging, I've noticed that the CDOFeature for argument of
>> CDORevisionImpl.getValue(CDOFeature feature) is "coming from" the
>> EPackages... Since the cdoClass of that same revision does not
>> contain the CDOFeature in argument, can you tell me where I can find
>> code populating the list of features of that cdoClass, so I can check
>> where those features are coming from?
>>
>> Thanks,
>> Eric
>>
>> Eike Stepper wrote:
>>> Hi martin,
>>>
>>> From a quick look I saw that htere's a suspicious method in
>>> HibernateStoreReader:
>>>
>>>
>>> org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore Reader.copyCDOClasses(CDOPackage,
>>> CDOPackage)
>>>
>>> Could that be related?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> Martin Taal schrieb:
>>>> Hi Eric, Eike,
>>>> I will check this issue out later today, so no new insights I am
>>>> afraid.
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I think Martin told me about this issue recently. Seems to be a
>>>>> regression. We have not identified the root cause yet, but efforts
>>>>> ongoing...
>>>>>
>>>>> Martin, do you have new insights?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> Eric wrote:
>>>>>
>>>>>> Hi guys,
>>>>>
>>>>>> I'm trying to create a small test case and I decided to use
>>>>>> your model (model1) for my test case. My test case failed with
>>>>>> the following error (and I tried to run CDO's Hibernate test suite
>>>>>> and I get the same error for many testcases)
>>>>>
>>>>>> org.eclipse.net4j.util.transaction.TransactionException: Could not
>>>>>> determine type for: null, at table: address, for columns:
>>>>>> [org.hibernate.mapping.Column(preferred)]
>>>>>> at
>>>>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:240)
>>>>>
>>>>>> at
>>>>> org.eclipse.emf.cdo.tests.TransactionDeadLockTest.testCreate ManyTransaction(TransactionDeadLockTest.java:68)
>>>>>
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>>>> Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>>>> at
>>>>>> org.eclipse.net4j.tests.AbstractOMTest.runTest(AbstractOMTes t.java:68)
>>>>>>
>>>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>>>> at junit.framework.TestResult.run(TestResult.java:109)
>>>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>>>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:130)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>>>>>
>>>>>> at
>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:196)
>>>>>
>>>>>
>>>>>
>>>>>> What am I doing wrong here?
>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Guys,
>>>>>>>
>>>>>>> One idea popped into my mind although it's pretty unprobable: If
>>>>>>> there's something wrong with synchronization it could eventually
>>>>>>> happen that some state gets duplicated. But that would hardly be
>>>>>>> reproduceable.
>>>>>>>
>>>>>>> Martin, I have currently no code at hand, but I seem to recall
>>>>>>> that packages have to be initialized/post-processed after they
>>>>>>> have been received from a client (resolving forward references
>>>>>>> and so). This can only happen after all of several packages have
>>>>>>> arrived. It's also possible that I changed this mechanism to lazy
>>>>>>> getters. In this case these getters should not be called before
>>>>>>> all packages have arrived from the client. I'll have to clarify
>>>>>>> this tonight...
>>>>>>>
>>>>>>> Eric, is it possible that you send us a small test case that
>>>>>>> reproduces the problem, ideally attached to a Bugzilla?
>>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>>
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>
>>>>>>>> Hi Eric,
>>>>>>>> The CDOPropertyGetter is used to integrate hibernate with CDO.
>>>>>>>> During the
>>>>>>> application startup the
>>>>>>>> hibernate mapping is created and for each feature a property
>>>>>>>> getter/setter
>>>>>>> is created.
>>>>>>>> When persisting and reading an object from the db the
>>>>>>>> propertygetter/setter
>>>>>>> is used by hibernate to
>>>>>>>> get the data from/to the cdo object.
>>>>>>>
>>>>>>>> Eike, where does the revision get the cdoclass instance from?
>>>>>>>> The hibernate
>>>>>>> layer reads the
>>>>>>>> cdopackages from the db, so maybe it misses some initialization
>>>>>>>> code
>>>>>>> somewhere?
>>>>>>>> Also when writePackages is done then the hibernatelayer will not
>>>>>>>> replace
>>>>>>> cdoclasses/cdopackages if
>>>>>>>> the underlying ecore has not changed. So maybe the client does
>>>>>>>> writepackages
>>>>>>> with a new
>>>>>>>> cdopackage/cdoclass instance and the hibernate layer does not
>>>>>>>> replace it,
>>>>>>> while it should.
>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>
>


Re: [Teneo][CDO-Hibernate] Problem with CDOFeatures identity [message #617898 is a reply to message #119742] Thu, 24 April 2008 07:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Short update:

Martin and I worked together on this issue yesterday evening and we seem
to be on the track. It relates somehow to the Hibernate SessionFactory
being recreated for new packages (on commit and after server restart). We
keep you informed via the Bugzilla...

Cheers
/Eike


Previous Topic:emfatic
Next Topic:[CDO-Teneo-Hibernate] Experience report and errors: Migrating from classic MySQLAdapter-backed store
Goto Forum:
  


Current Time: Mon Mar 30 17:23:34 GMT 2020

Powered by FUDForum. Page generated in 0.03865 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top