Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1162611/#msg_1162611
persistence-related actions --- Save, SaveAs, etc.
Upon startup of the application that has several models loaded in to
EMFStore, I'm seeing huge numbers of commands being executed (many
thousands). When I trace them back I found that even getters like this
one are executed using commands.
A related issue is looping. In some cases, my action update methods end
up calling basic getters like ESLocalProject.getProjectName(), which in
turn creates another command, which invokes the CommandStackListener,
and so on creating a loop.
Is there another application pattern I should be using with EMFStore?
Should I be going around the external API and using the internal API
instead.
/**
*
* {@inheritDoc}
*
* @see org.eclipse.emf.emfstore.client.ESProject#getProjectName()
*/
public String getProjectName() {
return RunESCommand.runWithResult(new Callable<String>() {
public String call() throws Exception {
return toInternalAPI().getProjectName();
}
});
}]]>Scott Dybiec2013-10-30T13:53:05-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1164338/#msg_1164338
thank you for your report! Comments inline...
> Upon startup of the application that has several models loaded in to
> EMFStore, I'm seeing huge numbers of commands being executed (many
> thousands). When I trace them back I found that even getters like this
> one are executed using commands.
I would expect a couple of commands per adding one model. Is it many
models or many EObjects that you add? Does it slow down your start-up
significantly?
> A related issue is looping. In some cases, my action update methods end
> up calling basic getters like ESLocalProject.getProjectName(), which in
> turn creates another command, which invokes the CommandStackListener,
> and so on creating a loop.
> Is there another application pattern I should be using with EMFStore?
> Should I be going around the external API and using the internal API
> instead.
The actions are UI actions I assume? Do you want to track if there are
changes to be saved locally or changes pending to be synchronized with
the server? A client could have pending changes for the server but still
everything saved locally. For the following I assume you want to track
the clients local save state:
I think it would be a better to track changes to the dirty state of a
project differently. You could register a
org.eclipse.emf.emfstore.internal.client.observer.SaveStateChangedObserver
with ESWorkspaceProviderImpl.getObserverBus().register(observer) to be
notified about changes in the save state of a project.
Let me know if I got your wrong here.
Hope this helps!
Cheers,
Maximilian
--
Maximilian Kögel
Get Professional Eclipse Support: http://eclipsesource.com/munich]]>Maximilian Koegel2013-10-31T16:04:32-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1164482/#msg_1164482
I found the source of the storm to be the
ESLocalProject.getProjectName() call.
First as little background. To make naming, identifying and accessing
model element more user friendly, I have grafted a virtual project
hierarchical directory structure on top of EMFStore's flat model element
project space. This project directory model is modeled in Ecore
(naturally!) and an instance of this model is stored as a model element
in each project. As you can imagine with all access to model elements at
startup going through this project directory there were lots of calls to
ESLocalProject.getProjectName(). By modifying the
ESLocalProject.getProjectName() method to eliminate the Command creation
from this API method, both the looping and storms problems went away. Is
the ESCommand creation necessary for this getter method? If not, I'd
like to request that you remove it.
Since my application has to use both file-based XMI resources as well as
EMFStore resources, if possible I'd prefer to use the same code to
monitor local save state ---- a CommandStackListener in this case. If
that really won't work, then I'll adopt the SaveStateChangedObserver.
Lastly, is there any thought in creating a feature to support a
hierarchical naming structure similar to my project directory idea on
top of EMFStore?
Scott
On 10/31/2013 12:04 PM, Maximilian Koegel wrote:
> Hi Scott,
>
> thank you for your report! Comments inline...
>> Upon startup of the application that has several models loaded in to
>> EMFStore, I'm seeing huge numbers of commands being executed (many
>> thousands). When I trace them back I found that even getters like this
>> one are executed using commands.
> I would expect a couple of commands per adding one model. Is it many
> models or many EObjects that you add? Does it slow down your start-up
> significantly?
>
>> A related issue is looping. In some cases, my action update methods end
>> up calling basic getters like ESLocalProject.getProjectName(), which in
>> turn creates another command, which invokes the CommandStackListener,
>> and so on creating a loop.
>> Is there another application pattern I should be using with EMFStore?
>> Should I be going around the external API and using the internal API
>> instead.
> The actions are UI actions I assume? Do you want to track if there are
> changes to be saved locally or changes pending to be synchronized with
> the server? A client could have pending changes for the server but still
> everything saved locally. For the following I assume you want to track
> the clients local save state:
> I think it would be a better to track changes to the dirty state of a
> project differently. You could register a
> org.eclipse.emf.emfstore.internal.client.observer.SaveStateChangedObserver
> with ESWorkspaceProviderImpl.getObserverBus().register(observer) to be
> notified about changes in the save state of a project.
> Let me know if I got your wrong here.
>
> Hope this helps!
>
> Cheers,
> Maximilian
>
>]]>Scott Dybiec2013-10-31T18:11:03-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1170478/#msg_1170478
Comments inline.
> Yes, the appl is tracking local save state.
>
> I found the source of the storm to be the
> ESLocalProject.getProjectName() call.
>
> First as little background. To make naming, identifying and accessing
> model element more user friendly, I have grafted a virtual project
> hierarchical directory structure on top of EMFStore's flat model element
> project space. This project directory model is modeled in Ecore
> (naturally!) and an instance of this model is stored as a model element
> in each project. As you can imagine with all access to model elements at
> startup going through this project directory there were lots of calls to
> ESLocalProject.getProjectName(). By modifying the
> ESLocalProject.getProjectName() method to eliminate the Command creation
> from this API method, both the looping and storms problems went away. Is
> the ESCommand creation necessary for this getter method? If not, I'd
> like to request that you remove it.
The command wrapping happens because we'd like to ensure that getters
work as expected when using EMFStore in conjunction with EMF
Transaction. Otherwise it would be possible to change the project's name
while someone is reading it.
I'm afraid that we won't change this behaviour and that you either have
to stick with using the internal API, or as Max suggested, using the
SaveStateChangedObserver. The latter currently is internal API but it
would be no problem to make it part of the public API.
>
> Since my application has to use both file-based XMI resources as well as
> EMFStore resources, if possible I'd prefer to use the same code to
> monitor local save state ---- a CommandStackListener in this case. If
> that really won't work, then I'll adopt the SaveStateChangedObserver.
>
> Lastly, is there any thought in creating a feature to support a
> hierarchical naming structure similar to my project directory idea on
> top of EMFStore?
Get Professional Eclipse Support: http://eclipsesource.com/munich]]>Edgar Mueller2013-11-04T17:20:12-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1170874/#msg_1170874
I see the need for supporting transactional access to EMFStore and
understand your design decision. If a command is created even for
reads, then making the SaveStateChangedObserver part of the public API
is quite important.
However, I don't think that the TransactionalEditingDomain requires a
command to maintain exclusive access during reads. This pattern should work:
public T runReadTransaction(RunnableWithResult<T> runnable)
throws InterruptedException {
TransactionalEditingDomain domain = (TransactionalEditingDomain)
getEditingDomain();
domain.runExclusive(runnable);
return runnable.getResult();
}
I ran into a similar problem with my application's support for
TransactionalEditingDomain, but opted for a solution that keeps access
lightweight for client's that don't need to support multi-threaded
access or those that want to manage the locking themselves outside of
the TransactionalEditingDomain.
Not sure, but perhaps the TransactionRunnerFactory pattern below could
be adapted to provide EMFStore-based applications with a way to choose
the transactional quality of service (TransactionManagementMethod),
while avoiding the creation of commands for reads.
public interface ITransactionRunner<T> {
public T runReadTransaction(RunnableWithResult<T> runnable) throws
InterruptedException;
public void runWriteTransaction(Runnable runnable);
}
public class TransactionRunnerFactory<T> {
public ITransactionRunner<T> createTransactionRunner() {
ITransactionRunner<T> runner;
switch (transactionManagementMethod) {
case NON_TRANSACTIONAL:
runner = new ITransactionRunner<T>() {
@Override
public T runReadTransaction(RunnableWithResult<T> runnable) {
runnable.run();
return runnable.getResult();
}
};
break;
case READ_WRITE_LOCK:
runner = new ITransactionRunner<T>() {
public ResourceSet getResourceSet() {
return getEditingDomain().getResourceSet();
}
public MonitoredCommandStack getCommandStack() {
return (MonitoredCommandStack) getEditingDomain().getCommandStack();
}
public TransactionManagementMethod getTransactionManagementMethod() {
return transactionManagementMethod;
}
}
On 11/4/2013 12:20 PM, Edgar Mueller wrote:
> Hi Scott,
>
> Comments inline.
>
>> Yes, the appl is tracking local save state.
>>
>> I found the source of the storm to be the
>> ESLocalProject.getProjectName() call.
>>
>> First as little background. To make naming, identifying and accessing
>> model element more user friendly, I have grafted a virtual project
>> hierarchical directory structure on top of EMFStore's flat model element
>> project space. This project directory model is modeled in Ecore
>> (naturally!) and an instance of this model is stored as a model element
>> in each project. As you can imagine with all access to model elements at
>> startup going through this project directory there were lots of calls to
>> ESLocalProject.getProjectName(). By modifying the
>> ESLocalProject.getProjectName() method to eliminate the Command creation
>> from this API method, both the looping and storms problems went away. Is
>> the ESCommand creation necessary for this getter method? If not, I'd
>> like to request that you remove it.
>
> The command wrapping happens because we'd like to ensure that getters
> work as expected when using EMFStore in conjunction with EMF
> Transaction. Otherwise it would be possible to change the project's name
> while someone is reading it.
> I'm afraid that we won't change this behaviour and that you either have
> to stick with using the internal API, or as Max suggested, using the
> SaveStateChangedObserver. The latter currently is internal API but it
> would be no problem to make it part of the public API.
>
>>
>> Since my application has to use both file-based XMI resources as well as
>> EMFStore resources, if possible I'd prefer to use the same code to
>> monitor local save state ---- a CommandStackListener in this case. If
>> that really won't work, then I'll adopt the SaveStateChangedObserver.
>>
>> Lastly, is there any thought in creating a feature to support a
>> hierarchical naming structure similar to my project directory idea on
>> top of EMFStore?
>
> Please open up a feature request in Bugzilla:
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFStore
>
> Thanks!
>
> Cheers,
> Edgar
>
>]]>Scott Dybiec2013-11-04T23:21:39-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1172079/#msg_1172079
comments inline
> I see the need for supporting transactional access to EMFStore and
> understand your design decision. If a command is created even for
> reads, then making the SaveStateChangedObserver part of the public API
> is quite important.
Ok, we'll make the observer part of the public API then in the next release.
> However, I don't think that the TransactionalEditingDomain requires a
> command to maintain exclusive access during reads. This pattern should
> work:
Yes, this would work, but it would also add a dependency to EMF
transaction. Currently, the actual editing domain in use is completely
transparent to EMFStore . In fact, transaction support is gained by
adding a single plugin (org.eclipse.emf.emfstore.client.transaction).
We'll discuss your proposed pattern and see if we can come up with a
solution which would not make it necessary to add a EMF transaction
dependency to the core, but I don't think that an actual solution will
make it anytime soon into a release.
Cheers,
Edgar
--
Edgar Mueller
Get Professional Eclipse Support: http://eclipsesource.com/munich]]>Edgar Mueller2013-11-05T17:37:00-00:00Re: [EMFStore] command stack notification storms
https://www.eclipse.org/forums/index.php/mv/msg/574076/1172200/#msg_1172200
TransactionRunnerFactory could be an extension, making the dependency on
EMF Transaction optional.
Scott
On 11/5/2013 12:37 PM, Edgar Mueller wrote:
> Hi Scott,
>
> comments inline
>
>> I see the need for supporting transactional access to EMFStore and
>> understand your design decision. If a command is created even for
>> reads, then making the SaveStateChangedObserver part of the public API
>> is quite important.
> Ok, we'll make the observer part of the public API then in the next
> release.
>
>> However, I don't think that the TransactionalEditingDomain requires a
>> command to maintain exclusive access during reads. This pattern should
>> work:
> Yes, this would work, but it would also add a dependency to EMF
> transaction. Currently, the actual editing domain in use is completely
> transparent to EMFStore . In fact, transaction support is gained by
> adding a single plugin (org.eclipse.emf.emfstore.client.transaction).
>
> We'll discuss your proposed pattern and see if we can come up with a
> solution which would not make it necessary to add a EMF transaction
> dependency to the core, but I don't think that an actual solution will
> make it anytime soon into a release.
>
> Cheers,
> Edgar
>]]>Scott Dybiec2013-11-05T19:25:07-00:00