Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO] all tests successfull, next step ?
[CDO] all tests successfull, next step ? [message #99307] Tue, 16 October 2007 21:31 Go to next message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

I have finally completed the first step in evaulating the new CDO.

I have derby running, and now all the CDO/NET4j tests are successfull. I
used the cdo-server.xml file in your quick start writeup.

Also, I have my model now built for CDO. I used the native CDO objects,
edited the genmodel, and did a gen-all. All my model objects now extend
CDOObjectImpl and the interfaces extend CDOObject.

So now what is the best next step.?

Can I modify the cdo-server.xml easily for my repo.? Also, can I define
the TCP acceptor in the xml file.?

Thanks,
Mark.
Re: [CDO] all tests successfull, next step ? [message #99332 is a reply to message #99307] Wed, 17 October 2007 08:26 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------060501010905080204090708
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark schrieb:
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Eike,
<br>
<br>
I have finally completed the first step in evaulating the new CDO.
<br>
I have derby running, and now all the CDO/NET4j tests are successfull.
I used the cdo-server.xml file in your quick start writeup.
<br>
</blockquote>
To ease the initial setup of a CDO server I've committed a separate
feature in features/org.eclipse.emf.cdo.server.product which you can
use to easily create a cdo-server.zip. In it you'll find everything
preconfigured, including a derby-server.bat and a cdo-server.exe. You
might find it convenient for Windows...<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Also, I have my model now built for CDO. I used the native
CDO objects, edited the genmodel, and did a gen-all. All my model
objects now extend CDOObjectImpl and the interfaces extend CDOObject.
<br>
So now what is the best next step.?
<br>
</blockquote>
I'm not very sure what you mean. Have you already used the "CDO
Sessions" view? It is the main access point from a client UI to a
server repository. From there you can open CDO sessions:<br>
<br>
<img src="cid:part1.09010705.08040300@sympedia.de" alt=""><br>
<br>
If the session was successfully opened the view should look like:<br>
<br>
<img src="cid:part2.02030206.04080500@sympedia.de" alt=""><br>
<br>
If there are no user packages in the repository, yet, you need to open
the Package Manager of the session to add the packages you wish to
commit to the repository in your first transaction:<br>
<br>
<img src="cid:part3.05010302.03000608@sympedia.de" alt=""><br>
<br>
Since you generated your models for CDO click the "Generated..." button:<br>
<br>
<img src="cid:part4.05090307.04000509@sympedia.de" alt=""><br>
<br>
Select all the packages you want to use. CDO native packages show up
completely with cyan icons. Legacy packages have magenta icons and
converted legacy packages (AspectJ weaver) have a magenta icon with a
small cyan corner. You can select multiple packages to be used in the
editors of the session but only those that are actually used to create
instances will be committed to the repository. Packages that have been
committed to the repository once are not required to be added to
subsequent sessions thereafter. They are stored in the repository and
will be transfered to client's sessions as needed. You can always see
them in the Package Manager dialog.<br>
<br>
When you have added your packages you'll want to start your first
transaction through the context menu of the session. CDO transactions
are considered light weight compared to CDO sessions. You can open as
many of them as you want. Each transaction encapsulates a separate EMF
ResourceSet. All the objects in different transactions of the same
session share their state. Of course only until they're modified in the
scope of a particular transaction.<br>
<br>
<img src="cid:part5.01090303.03020909@sympedia.de" alt=""><br>
<br>
Next you'll want to create your first resources through the context
menu of a transaction:<br>
<br>
<img src="cid:part6.01060900.02050900@sympedia.de" alt=""><br>
<br>
This will change the CDO sessions view:<br>
<br>
<img src="cid:part7.02080703.00050205@sympedia.de" alt=""><br>
<br>
.... and open a CDO Editor with an empty resource as input. Now you can
add multiple root objects through "New Root" in the context menu of the
editor:<br>
<br>
<img src="cid:part8.09030804.04080406@sympedia.de" alt=""><br>
<br>
Could look like this:<br>
<br>
<img src="cid:part9.07030009.08090003@sympedia.de" alt=""><br>
<br>
The numbers in brackets are the CDOIDs of the objects. They're always
even (means user instances in contrast to meta instances from the
package registry) and negative (means state NEW) before you commit the
transaction. After the commit they become positive and stay even. It's
only technical but the equation -newID == cleanID is usually not true.<br>
<br>
Saving the editor will commit the transaction (not only that editor if
multiple editors are open on the same transaction). Another way to
commit a transaction (and the only way to roll it back) is via the
transaction's context menu in the CDO Sessions view.<br>
<br>
You can also load resources into read-only views instead of
transactions. Another option is to view historical states of the
repository by opening an audit view on the session. In fact
transactions and audits are special views. All of them share the
objects' state as long as it is the same.<br>
<br>
I think these are the main points about the CDO user interface (which
is no longer considered only an example in this CDO version, though it
is not mandatory if you want to use the CDO core API to build up your
own UI).<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Can I modify the cdo-server.xml easily for my repo.? </blockquote>
Yes. But please note that vertical mapping strategy is not implemented,
yet. Due to your former input I prioritized the horizontal mapping
strategy. Also the reference mappings other than
ONE_TABLE_PER_REFERENCE are not tested, yet. But I think this will also
fit your requirements.<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Also, can I define the TCP acceptor in the xml file.?
<br>
</blockquote>
<br>
Yes, more recent builds already have the following in the
cdo-server.xml:<br>
<br>
Re: [CDO] all tests successfull, next step ? [message #99549 is a reply to message #99332] Wed, 17 October 2007 21:57 Go to previous messageGo to next message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

Made some progress today.

I did basically the following:

IManagedContainer container = ContainerUtil.createContainer();
Net4jUtil.prepareContainer(container);
TCPUtil.prepareContainer(container);
CDOUtil.prepareContainer(container, true);

CDOSession session = CDOUtil.openSession(TCPUtil.getConnector(container,
"localhost"), "repo1");
session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
transaction = session.openTransaction();
resource = transaction.createResource("/res1");

Then I create a root object and added to the resource.

When I then did a commit on the transaction I got the following on the
server console.
...
Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
Thread-20 [debug.protocol] Reading 1 new resources
Thread-20 [debug.revision] Reading revision: ID=-2,
classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0, 0),
className=CDOResource, version=1, created=0, revised=0, resource=-2,
container=NULL, feature=0
Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
type=STRING): /res1
Thread-20 [debug.revision] Read feature CDOFeature(ID=2, name=contents,
type=OBJECT): size=1
Thread-20 [debug.revision] -4
Exception in thread "Thread-20"
org.eclipse.net4j.util.ImplementationError: Store writer returned bad
CDOID NULL
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Re: [CDO] all tests successfull, next step ? [message #99561 is a reply to message #99549] Wed, 17 October 2007 23:04 Go to previous messageGo to next message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

On the second, and subsequent invocations, I am getting the following
error:

Error creating the view.
java.sql.SQLException: A string constant starting with ''<?xml
version="1.0" encoding="ASCII"?>
<ecore:EPackage xmi:&' is too long.

When I call transaction.commit()

Mark.
Re: [CDO] all tests successfull, next step ? [message #99573 is a reply to message #99561] Thu, 18 October 2007 06:16 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Mark,

It seems that the xml form of your model is too long for being inserted
into the database via an unprepared sql statement. If you open a bug
against 0.8 I can change that statement to be a prepared one.

Cheers
/Eike


Mark schrieb:
> Eike,
>
> On the second, and subsequent invocations, I am getting the following
> error:
>
> Error creating the view.
> java.sql.SQLException: A string constant starting with ''<?xml
> version="1.0" encoding="ASCII"?>
> <ecore:EPackage xmi:&' is too long.
>
> When I call transaction.commit()
>
> Mark.
>
Re: [CDO] all tests successfull, next step ? [message #99584 is a reply to message #99549] Thu, 18 October 2007 06:57 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Mark,

I wrongly thought that you are using CDO in an Eclipse environment and
not standalone. If you were using a plugin based environment it'd be
easier to use an extension point based container:

IConnector connector =
TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
CDOSession session = CDOUtil.openSession(connector, "repo1");

To void the dependency on the TCP transport plugin you could also write:

IConnector connector =
(IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
"tcp", "localhost");

BTW if you're really writing a non-interactive application you should
register your model package only ever prior to the first commit.
Subsequent openSession() calls will register package proxies for
packages that exist in the repository already.

Now to the error:
"Mapping ID: -1943 --> 1942" is not ok already since odd ids must never
become even and vice versa, even if they change sign when they
transition from NEW to CLEAN. Also the store should never return a NULL
ID for new objects. Both can IMHO only happen if your server has not
been properly shutdown the last time. Can you please look into your log
if there are lines like:

[WARN] Detected restart after crash
[ERROR] repairAfterCrash not yet implemented

May be I should have mentioned earlier that the DB store implementation
requires that OSGi is properly shutdown, for example via "close" console
command. If you're running standalone make sure to deactivate the
container or at least the repository:

LifecycleUtil.deactivate(container);

xor:

repositories = repositoryConfigurator.configure(configFile);
// server running
LifecycleUtil.deactivate(repositories[i]);

I will prioritize the implementation of the repairAfterCrash() method in
DBStore so that the log will read something like:

[WARN] Detected restart after crash
[INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643

You might want to watch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue

HTH and sorry for the inconvenience
/Eike


Mark schrieb:
> Eike,
>
> Made some progress today.
>
> I did basically the following:
>
> IManagedContainer container = ContainerUtil.createContainer();
> Net4jUtil.prepareContainer(container);
> TCPUtil.prepareContainer(container);
> CDOUtil.prepareContainer(container, true);
>
> CDOSession session =
> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
> "repo1");
>
> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
> transaction = session.openTransaction();
> resource = transaction.createResource("/res1");
>
> Then I create a root object and added to the resource.
>
> When I then did a commit on the transaction I got the following on the
> server console.
> ...
> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
> Thread-20 [debug.protocol] Reading 1 new resources
> Thread-20 [debug.revision] Reading revision: ID=-2,
> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
> 0), className=CDOResource, version=1, created=0, revised=0,
> resource=-2, container=NULL, feature=0
> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
> type=STRING): /res1
> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
> name=contents, type=OBJECT): size=1
> Thread-20 [debug.revision] -4
> Exception in thread "Thread-20"
> org.eclipse.net4j.util.ImplementationError: Store writer returned bad
> CDOID NULL
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
> at java.lang.Thread.run(Thread.java:595)
>
>
>
>
Re: [CDO] all tests successfull, next step ? [message #99642 is a reply to message #99584] Thu, 18 October 2007 15:24 Go to previous messageGo to next message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

The server is not standalone, that is, it is an Eclipse Product based on
your feature/...server.product.

more inline.

Mark.

Eike Stepper wrote:

> Mark,

> I wrongly thought that you are using CDO in an Eclipse environment and
> not standalone. If you were using a plugin based environment it'd be
> easier to use an extension point based container:

> IConnector connector =
> TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
> CDOSession session = CDOUtil.openSession(connector, "repo1");

> To void the dependency on the TCP transport plugin you could also write:

> IConnector connector =
>
(IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
> "tcp", "localhost");

> BTW if you're really writing a non-interactive application you should
> register your model package only ever prior to the first commit.
> Subsequent openSession() calls will register package proxies for
> packages that exist in the repository already.

> Now to the error:
> "Mapping ID: -1943 --> 1942" is not ok already since odd ids must never
> become even and vice versa, even if they change sign when they
> transition from NEW to CLEAN. Also the store should never return a NULL
> ID for new objects. Both can IMHO only happen if your server has not
> been properly shutdown the last time. Can you please look into your log
> if there are lines like:

> [WARN] Detected restart after crash
> [ERROR] repairAfterCrash not yet implemented

Yes these lines are in my log.

> May be I should have mentioned earlier that the DB store implementation
> requires that OSGi is properly shutdown, for example via "close" console
> command. If you're running standalone make sure to deactivate the
> container or at least the repository:

> LifecycleUtil.deactivate(container);

I will do this, does this imply I should also do something like
LifecycleUtilactivate()..?

> xor:

> repositories = repositoryConfigurator.configure(configFile);
> // server running
> LifecycleUtil.deactivate(repositories[i]);

> I will prioritize the implementation of the repairAfterCrash() method in
> DBStore so that the log will read something like:

> [WARN] Detected restart after crash
> [INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643

> You might want to watch
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue

> HTH and sorry for the inconvenience
> /Eike


> Mark schrieb:
>> Eike,
>>
>> Made some progress today.
>>
>> I did basically the following:
>>
>> IManagedContainer container = ContainerUtil.createContainer();
>> Net4jUtil.prepareContainer(container);
>> TCPUtil.prepareContainer(container);
>> CDOUtil.prepareContainer(container, true);
>>
>> CDOSession session =
>> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
>> "repo1");
>>
>> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
>> transaction = session.openTransaction();
>> resource = transaction.createResource("/res1");
>>
>> Then I create a root object and added to the resource.
>>
>> When I then did a commit on the transaction I got the following on the
>> server console.
>> ...
>> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
>> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
>> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
>> Thread-20 [debug.protocol] Reading 1 new resources
>> Thread-20 [debug.revision] Reading revision: ID=-2,
>> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
>> 0), className=CDOResource, version=1, created=0, revised=0,
>> resource=-2, container=NULL, feature=0
>> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
>> type=STRING): /res1
>> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
>> name=contents, type=OBJECT): size=1
>> Thread-20 [debug.revision] -4
>> Exception in thread "Thread-20"
>> org.eclipse.net4j.util.ImplementationError: Store writer returned bad
>> CDOID NULL
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>>
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>>
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>>
>>
>>
Re: [CDO] all tests successfull, next step ? [message #99650 is a reply to message #99642] Thu, 18 October 2007 16:40 Go to previous message
Eclipse User
Originally posted by: stepper.sympedia.de

Mark,

If your server is based on the server.product feature then the lifecycle
of the repositories should be controlled by the headless
CDOServerApplication. If you want to control the server remotely (or via
scripts) you could add a port to the -console switch in cdo-server.ini.
Then you can telnet to that port and use the OSGi console to shutdown
with "close"+enter.

The repairAfterCrash method is already implemented now so the only
effect of a server crash should be a longer (depending on the used
mapping strategy) restart.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713)

BTW. the activation of the repository is controlled by the
RepositoryConfigurator. No need to do it yourself. It reads the
cdo-server.xml, creates the needed objects and registers the
repositories with the container so that it can further control the
lifecycle.

Cheers
/Eike



Mark schrieb:
> Eike,
>
> The server is not standalone, that is, it is an Eclipse Product based
> on your feature/...server.product.
>
> more inline.
>
> Mark.
>
> Eike Stepper wrote:
>
>> Mark,
>
>> I wrongly thought that you are using CDO in an Eclipse environment
>> and not standalone. If you were using a plugin based environment it'd
>> be easier to use an extension point based container:
>
>> IConnector connector =
>> TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
>> CDOSession session = CDOUtil.openSession(connector, "repo1");
>
>> To void the dependency on the TCP transport plugin you could also write:
>
>> IConnector connector =
> (IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
>
>> "tcp", "localhost");
>
>> BTW if you're really writing a non-interactive application you should
>> register your model package only ever prior to the first commit.
>> Subsequent openSession() calls will register package proxies for
>> packages that exist in the repository already.
>
>> Now to the error:
>> "Mapping ID: -1943 --> 1942" is not ok already since odd ids must
>> never become even and vice versa, even if they change sign when they
>> transition from NEW to CLEAN. Also the store should never return a
>> NULL ID for new objects. Both can IMHO only happen if your server has
>> not been properly shutdown the last time. Can you please look into
>> your log if there are lines like:
>
>> [WARN] Detected restart after crash
>> [ERROR] repairAfterCrash not yet implemented
>
> Yes these lines are in my log.
>
>> May be I should have mentioned earlier that the DB store
>> implementation requires that OSGi is properly shutdown, for example
>> via "close" console command. If you're running standalone make sure
>> to deactivate the container or at least the repository:
>
>> LifecycleUtil.deactivate(container);
>
> I will do this, does this imply I should also do something like
> LifecycleUtilactivate()..?
>
>> xor:
>
>> repositories = repositoryConfigurator.configure(configFile);
>> // server running
>> LifecycleUtil.deactivate(repositories[i]);
>
>> I will prioritize the implementation of the repairAfterCrash() method
>> in DBStore so that the log will read something like:
>
>> [WARN] Detected restart after crash
>> [INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643
>
>> You might want to watch
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue
>
>> HTH and sorry for the inconvenience
>> /Eike
>
>
>> Mark schrieb:
>>> Eike,
>>>
>>> Made some progress today.
>>>
>>> I did basically the following:
>>>
>>> IManagedContainer container = ContainerUtil.createContainer();
>>> Net4jUtil.prepareContainer(container);
>>> TCPUtil.prepareContainer(container);
>>> CDOUtil.prepareContainer(container, true);
>>> CDOSession session =
>>> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
>>> "repo1");
>>> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
>>> transaction = session.openTransaction();
>>> resource = transaction.createResource("/res1");
>>>
>>> Then I create a root object and added to the resource.
>>>
>>> When I then did a commit on the transaction I got the following on
>>> the server console.
>>> ...
>>> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
>>> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
>>> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
>>> Thread-20 [debug.protocol] Reading 1 new resources
>>> Thread-20 [debug.revision] Reading revision: ID=-2,
>>> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
>>> 0), className=CDOResource, version=1, created=0, revised=0,
>>> resource=-2, container=NULL, feature=0
>>> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
>>> type=STRING): /res1
>>> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
>>> name=contents, type=OBJECT): size=1
>>> Thread-20 [debug.revision] -4
>>> Exception in thread "Thread-20"
>>> org.eclipse.net4j.util.ImplementationError: Store writer returned
>>> bad CDOID NULL
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
>>>
>>> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
>>>
>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
>>>
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>>
>>>
>>>
>
Re: [CDO] all tests successfull, next step ? [message #610036 is a reply to message #99307] Wed, 17 October 2007 08:26 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5525
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060501010905080204090708
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark schrieb:
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Eike,
<br>
<br>
I have finally completed the first step in evaulating the new CDO.
<br>
I have derby running, and now all the CDO/NET4j tests are successfull.
I used the cdo-server.xml file in your quick start writeup.
<br>
</blockquote>
To ease the initial setup of a CDO server I've committed a separate
feature in features/org.eclipse.emf.cdo.server.product which you can
use to easily create a cdo-server.zip. In it you'll find everything
preconfigured, including a derby-server.bat and a cdo-server.exe. You
might find it convenient for Windows...<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Also, I have my model now built for CDO. I used the native
CDO objects, edited the genmodel, and did a gen-all. All my model
objects now extend CDOObjectImpl and the interfaces extend CDOObject.
<br>
So now what is the best next step.?
<br>
</blockquote>
I'm not very sure what you mean. Have you already used the "CDO
Sessions" view? It is the main access point from a client UI to a
server repository. From there you can open CDO sessions:<br>
<br>
<img src="cid:part1.09010705.08040300@sympedia.de" alt=""><br>
<br>
If the session was successfully opened the view should look like:<br>
<br>
<img src="cid:part2.02030206.04080500@sympedia.de" alt=""><br>
<br>
If there are no user packages in the repository, yet, you need to open
the Package Manager of the session to add the packages you wish to
commit to the repository in your first transaction:<br>
<br>
<img src="cid:part3.05010302.03000608@sympedia.de" alt=""><br>
<br>
Since you generated your models for CDO click the "Generated..." button:<br>
<br>
<img src="cid:part4.05090307.04000509@sympedia.de" alt=""><br>
<br>
Select all the packages you want to use. CDO native packages show up
completely with cyan icons. Legacy packages have magenta icons and
converted legacy packages (AspectJ weaver) have a magenta icon with a
small cyan corner. You can select multiple packages to be used in the
editors of the session but only those that are actually used to create
instances will be committed to the repository. Packages that have been
committed to the repository once are not required to be added to
subsequent sessions thereafter. They are stored in the repository and
will be transfered to client's sessions as needed. You can always see
them in the Package Manager dialog.<br>
<br>
When you have added your packages you'll want to start your first
transaction through the context menu of the session. CDO transactions
are considered light weight compared to CDO sessions. You can open as
many of them as you want. Each transaction encapsulates a separate EMF
ResourceSet. All the objects in different transactions of the same
session share their state. Of course only until they're modified in the
scope of a particular transaction.<br>
<br>
<img src="cid:part5.01090303.03020909@sympedia.de" alt=""><br>
<br>
Next you'll want to create your first resources through the context
menu of a transaction:<br>
<br>
<img src="cid:part6.01060900.02050900@sympedia.de" alt=""><br>
<br>
This will change the CDO sessions view:<br>
<br>
<img src="cid:part7.02080703.00050205@sympedia.de" alt=""><br>
<br>
.... and open a CDO Editor with an empty resource as input. Now you can
add multiple root objects through "New Root" in the context menu of the
editor:<br>
<br>
<img src="cid:part8.09030804.04080406@sympedia.de" alt=""><br>
<br>
Could look like this:<br>
<br>
<img src="cid:part9.07030009.08090003@sympedia.de" alt=""><br>
<br>
The numbers in brackets are the CDOIDs of the objects. They're always
even (means user instances in contrast to meta instances from the
package registry) and negative (means state NEW) before you commit the
transaction. After the commit they become positive and stay even. It's
only technical but the equation -newID == cleanID is usually not true.<br>
<br>
Saving the editor will commit the transaction (not only that editor if
multiple editors are open on the same transaction). Another way to
commit a transaction (and the only way to roll it back) is via the
transaction's context menu in the CDO Sessions view.<br>
<br>
You can also load resources into read-only views instead of
transactions. Another option is to view historical states of the
repository by opening an audit view on the session. In fact
transactions and audits are special views. All of them share the
objects' state as long as it is the same.<br>
<br>
I think these are the main points about the CDO user interface (which
is no longer considered only an example in this CDO version, though it
is not mandatory if you want to use the CDO core API to build up your
own UI).<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Can I modify the cdo-server.xml easily for my repo.? </blockquote>
Yes. But please note that vertical mapping strategy is not implemented,
yet. Due to your former input I prioritized the horizontal mapping
strategy. Also the reference mappings other than
ONE_TABLE_PER_REFERENCE are not tested, yet. But I think this will also
fit your requirements.<br>
<br>
<blockquote
cite="mid:db7a4ee61b9ca337363bdd45326d6ac8$1@www.eclipse.org"
type="cite">Also, can I define the TCP acceptor in the xml file.?
<br>
</blockquote>
<br>
Yes, more recent builds already have the following in the
cdo-server.xml:<br>
<br>
Re: [CDO] all tests successfull, next step ? [message #610062 is a reply to message #99332] Wed, 17 October 2007 21:57 Go to previous message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

Made some progress today.

I did basically the following:

IManagedContainer container = ContainerUtil.createContainer();
Net4jUtil.prepareContainer(container);
TCPUtil.prepareContainer(container);
CDOUtil.prepareContainer(container, true);

CDOSession session = CDOUtil.openSession(TCPUtil.getConnector(container,
"localhost"), "repo1");
session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
transaction = session.openTransaction();
resource = transaction.createResource("/res1");

Then I create a root object and added to the resource.

When I then did a commit on the transaction I got the following on the
server console.
...
Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
Thread-20 [debug.protocol] Reading 1 new resources
Thread-20 [debug.revision] Reading revision: ID=-2,
classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0, 0),
className=CDOResource, version=1, created=0, revised=0, resource=-2,
container=NULL, feature=0
Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
type=STRING): /res1
Thread-20 [debug.revision] Read feature CDOFeature(ID=2, name=contents,
type=OBJECT): size=1
Thread-20 [debug.revision] -4
Exception in thread "Thread-20"
org.eclipse.net4j.util.ImplementationError: Store writer returned bad
CDOID NULL
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Re: [CDO] all tests successfull, next step ? [message #610064 is a reply to message #99549] Wed, 17 October 2007 23:04 Go to previous message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

On the second, and subsequent invocations, I am getting the following
error:

Error creating the view.
java.sql.SQLException: A string constant starting with ''<?xml
version="1.0" encoding="ASCII"?>
<ecore:EPackage xmi:&' is too long.

When I call transaction.commit()

Mark.
Re: [CDO] all tests successfull, next step ? [message #610066 is a reply to message #99561] Thu, 18 October 2007 06:16 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5525
Registered: July 2009
Senior Member
Mark,

It seems that the xml form of your model is too long for being inserted
into the database via an unprepared sql statement. If you open a bug
against 0.8 I can change that statement to be a prepared one.

Cheers
/Eike


Mark schrieb:
> Eike,
>
> On the second, and subsequent invocations, I am getting the following
> error:
>
> Error creating the view.
> java.sql.SQLException: A string constant starting with ''<?xml
> version="1.0" encoding="ASCII"?>
> <ecore:EPackage xmi:&' is too long.
>
> When I call transaction.commit()
>
> Mark.
>
Re: [CDO] all tests successfull, next step ? [message #610067 is a reply to message #99549] Thu, 18 October 2007 06:57 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5525
Registered: July 2009
Senior Member
Mark,

I wrongly thought that you are using CDO in an Eclipse environment and
not standalone. If you were using a plugin based environment it'd be
easier to use an extension point based container:

IConnector connector =
TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
CDOSession session = CDOUtil.openSession(connector, "repo1");

To void the dependency on the TCP transport plugin you could also write:

IConnector connector =
(IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
"tcp", "localhost");

BTW if you're really writing a non-interactive application you should
register your model package only ever prior to the first commit.
Subsequent openSession() calls will register package proxies for
packages that exist in the repository already.

Now to the error:
"Mapping ID: -1943 --> 1942" is not ok already since odd ids must never
become even and vice versa, even if they change sign when they
transition from NEW to CLEAN. Also the store should never return a NULL
ID for new objects. Both can IMHO only happen if your server has not
been properly shutdown the last time. Can you please look into your log
if there are lines like:

[WARN] Detected restart after crash
[ERROR] repairAfterCrash not yet implemented

May be I should have mentioned earlier that the DB store implementation
requires that OSGi is properly shutdown, for example via "close" console
command. If you're running standalone make sure to deactivate the
container or at least the repository:

LifecycleUtil.deactivate(container);

xor:

repositories = repositoryConfigurator.configure(configFile);
// server running
LifecycleUtil.deactivate(repositories[i]);

I will prioritize the implementation of the repairAfterCrash() method in
DBStore so that the log will read something like:

[WARN] Detected restart after crash
[INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643

You might want to watch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue

HTH and sorry for the inconvenience
/Eike


Mark schrieb:
> Eike,
>
> Made some progress today.
>
> I did basically the following:
>
> IManagedContainer container = ContainerUtil.createContainer();
> Net4jUtil.prepareContainer(container);
> TCPUtil.prepareContainer(container);
> CDOUtil.prepareContainer(container, true);
>
> CDOSession session =
> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
> "repo1");
>
> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
> transaction = session.openTransaction();
> resource = transaction.createResource("/res1");
>
> Then I create a root object and added to the resource.
>
> When I then did a commit on the transaction I got the following on the
> server console.
> ...
> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
> Thread-20 [debug.protocol] Reading 1 new resources
> Thread-20 [debug.revision] Reading revision: ID=-2,
> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
> 0), className=CDOResource, version=1, created=0, revised=0,
> resource=-2, container=NULL, feature=0
> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
> type=STRING): /res1
> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
> name=contents, type=OBJECT): size=1
> Thread-20 [debug.revision] -4
> Exception in thread "Thread-20"
> org.eclipse.net4j.util.ImplementationError: Store writer returned bad
> CDOID NULL
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
> at java.lang.Thread.run(Thread.java:595)
>
>
>
>
Re: [CDO] all tests successfull, next step ? [message #610078 is a reply to message #99584] Thu, 18 October 2007 15:24 Go to previous message
Mark Geib is currently offline Mark Geib
Messages: 432
Registered: July 2009
Senior Member
Eike,

The server is not standalone, that is, it is an Eclipse Product based on
your feature/...server.product.

more inline.

Mark.

Eike Stepper wrote:

> Mark,

> I wrongly thought that you are using CDO in an Eclipse environment and
> not standalone. If you were using a plugin based environment it'd be
> easier to use an extension point based container:

> IConnector connector =
> TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
> CDOSession session = CDOUtil.openSession(connector, "repo1");

> To void the dependency on the TCP transport plugin you could also write:

> IConnector connector =
>
(IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
> "tcp", "localhost");

> BTW if you're really writing a non-interactive application you should
> register your model package only ever prior to the first commit.
> Subsequent openSession() calls will register package proxies for
> packages that exist in the repository already.

> Now to the error:
> "Mapping ID: -1943 --> 1942" is not ok already since odd ids must never
> become even and vice versa, even if they change sign when they
> transition from NEW to CLEAN. Also the store should never return a NULL
> ID for new objects. Both can IMHO only happen if your server has not
> been properly shutdown the last time. Can you please look into your log
> if there are lines like:

> [WARN] Detected restart after crash
> [ERROR] repairAfterCrash not yet implemented

Yes these lines are in my log.

> May be I should have mentioned earlier that the DB store implementation
> requires that OSGi is properly shutdown, for example via "close" console
> command. If you're running standalone make sure to deactivate the
> container or at least the repository:

> LifecycleUtil.deactivate(container);

I will do this, does this imply I should also do something like
LifecycleUtilactivate()..?

> xor:

> repositories = repositoryConfigurator.configure(configFile);
> // server running
> LifecycleUtil.deactivate(repositories[i]);

> I will prioritize the implementation of the repairAfterCrash() method in
> DBStore so that the log will read something like:

> [WARN] Detected restart after crash
> [INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643

> You might want to watch
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue

> HTH and sorry for the inconvenience
> /Eike


> Mark schrieb:
>> Eike,
>>
>> Made some progress today.
>>
>> I did basically the following:
>>
>> IManagedContainer container = ContainerUtil.createContainer();
>> Net4jUtil.prepareContainer(container);
>> TCPUtil.prepareContainer(container);
>> CDOUtil.prepareContainer(container, true);
>>
>> CDOSession session =
>> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
>> "repo1");
>>
>> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
>> transaction = session.openTransaction();
>> resource = transaction.createResource("/res1");
>>
>> Then I create a root object and added to the resource.
>>
>> When I then did a commit on the transaction I got the following on the
>> server console.
>> ...
>> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
>> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
>> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
>> Thread-20 [debug.protocol] Reading 1 new resources
>> Thread-20 [debug.revision] Reading revision: ID=-2,
>> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
>> 0), className=CDOResource, version=1, created=0, revised=0,
>> resource=-2, container=NULL, feature=0
>> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
>> type=STRING): /res1
>> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
>> name=contents, type=OBJECT): size=1
>> Thread-20 [debug.revision] -4
>> Exception in thread "Thread-20"
>> org.eclipse.net4j.util.ImplementationError: Store writer returned bad
>> CDOID NULL
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>>
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>>
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>>
>>
>>
Re: [CDO] all tests successfull, next step ? [message #610080 is a reply to message #99642] Thu, 18 October 2007 16:40 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5525
Registered: July 2009
Senior Member
Mark,

If your server is based on the server.product feature then the lifecycle
of the repositories should be controlled by the headless
CDOServerApplication. If you want to control the server remotely (or via
scripts) you could add a port to the -console switch in cdo-server.ini.
Then you can telnet to that port and use the OSGi console to shutdown
with "close"+enter.

The repairAfterCrash method is already implemented now so the only
effect of a server crash should be a longer (depending on the used
mapping strategy) restart.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713)

BTW. the activation of the repository is controlled by the
RepositoryConfigurator. No need to do it yourself. It reads the
cdo-server.xml, creates the needed objects and registers the
repositories with the container so that it can further control the
lifecycle.

Cheers
/Eike



Mark schrieb:
> Eike,
>
> The server is not standalone, that is, it is an Eclipse Product based
> on your feature/...server.product.
>
> more inline.
>
> Mark.
>
> Eike Stepper wrote:
>
>> Mark,
>
>> I wrongly thought that you are using CDO in an Eclipse environment
>> and not standalone. If you were using a plugin based environment it'd
>> be easier to use an extension point based container:
>
>> IConnector connector =
>> TCPUtil.getConnector(IPluginContainer.INSTANCE, "localhost")
>> CDOSession session = CDOUtil.openSession(connector, "repo1");
>
>> To void the dependency on the TCP transport plugin you could also write:
>
>> IConnector connector =
> (IConnector)IPluginContainer.INSTANCE.getElement(ConnectorFa ctory.PRODUCT_GROUP,
>
>> "tcp", "localhost");
>
>> BTW if you're really writing a non-interactive application you should
>> register your model package only ever prior to the first commit.
>> Subsequent openSession() calls will register package proxies for
>> packages that exist in the repository already.
>
>> Now to the error:
>> "Mapping ID: -1943 --> 1942" is not ok already since odd ids must
>> never become even and vice versa, even if they change sign when they
>> transition from NEW to CLEAN. Also the store should never return a
>> NULL ID for new objects. Both can IMHO only happen if your server has
>> not been properly shutdown the last time. Can you please look into
>> your log if there are lines like:
>
>> [WARN] Detected restart after crash
>> [ERROR] repairAfterCrash not yet implemented
>
> Yes these lines are in my log.
>
>> May be I should have mentioned earlier that the DB store
>> implementation requires that OSGi is properly shutdown, for example
>> via "close" console command. If you're running standalone make sure
>> to deactivate the container or at least the repository:
>
>> LifecycleUtil.deactivate(container);
>
> I will do this, does this imply I should also do something like
> LifecycleUtilactivate()..?
>
>> xor:
>
>> repositories = repositoryConfigurator.configure(configFile);
>> // server running
>> LifecycleUtil.deactivate(repositories[i]);
>
>> I will prioritize the implementation of the repairAfterCrash() method
>> in DBStore so that the log will read something like:
>
>> [WARN] Detected restart after crash
>> [INFO] Repaired after crash: nextCDOID=2654, nextMetaID=643
>
>> You might want to watch
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206713 for this issue
>
>> HTH and sorry for the inconvenience
>> /Eike
>
>
>> Mark schrieb:
>>> Eike,
>>>
>>> Made some progress today.
>>>
>>> I did basically the following:
>>>
>>> IManagedContainer container = ContainerUtil.createContainer();
>>> Net4jUtil.prepareContainer(container);
>>> TCPUtil.prepareContainer(container);
>>> CDOUtil.prepareContainer(container, true);
>>> CDOSession session =
>>> CDOUtil.openSession(TCPUtil.getConnector(container, "localhost"),
>>> "repo1");
>>> session.getPackageRegistry().putEPackage(SrdPackage.eINSTANC E);
>>> transaction = session.openTransaction();
>>> resource = transaction.createResource("/res1");
>>>
>>> Then I create a root object and added to the resource.
>>>
>>> When I then did a commit on the transaction I got the following on
>>> the server console.
>>> ...
>>> Thread-20 [debug.revision] Mapping ID: -1943 --> 1942
>>> Thread-20 [debug.revision] Mapping ID: -1945 --> 1944
>>> Thread-20 [debug.revision] Mapping ID: -1947 --> 1946
>>> Thread-20 [debug.protocol] Reading 1 new resources
>>> Thread-20 [debug.revision] Reading revision: ID=-2,
>>> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
>>> 0), className=CDOResource, version=1, created=0, revised=0,
>>> resource=-2, container=NULL, feature=0
>>> Thread-20 [debug.revision] Read feature CDOFeature(ID=8, name=path,
>>> type=STRING): /res1
>>> Thread-20 [debug.revision] Read feature CDOFeature(ID=2,
>>> name=contents, type=OBJECT): size=1
>>> Thread-20 [debug.revision] -4
>>> Exception in thread "Thread-20"
>>> org.eclipse.net4j.util.ImplementationError: Store writer returned
>>> bad CDOID NULL
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.mapTemporaryID(CommitTransactionIndication.java :269)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readRevisions(CommitTransactionIndication.java: 239)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.readNewResources(CommitTransactionIndication.ja va:206)
>
>>>
>>> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
>>>
>>> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:130)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:118)
>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
>>>
>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
>>>
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>>
>>>
>>>
>
Previous Topic:[Compare] extensibility
Next Topic:[Compare] Non-eclipse context
Goto Forum:
  


Current Time: Tue Sep 23 22:33:09 GMT 2014

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

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