|Re: EMF transactions - why the special ExtendedPropertySheetPage? [message #989331 is a reply to message #989322]
||Wed, 05 December 2012 16:33
|| Christian W. Damus
Registered: July 2009
IIRC (it has been some years, now), the critical difference in this
extended property sheet page is that it performs UI refreshes in
read-only transactions, on the assumption that refreshes will read the
model. This is required for thread-safety amongst current reads and
writes, especially in proxy resolution and derived calculation of
On 2012-12-05 16:12:07 +0000, Fredrik Attebrant said:
> Why does EMF transaction have its own ExtendedPropertySheetPage?
> According to section4 in the blog
> http://techblog.goelite.org/making-your-emf-model-transactional/ it is
> to "substitute the non-transactional implementation" of
> ExtendedPropertySheetPage that EMF supplies. But there is no
> explaination as to why this is necessary.
> Looking at the methods refresh and selectionChanged I fail to see why
> this is necessary since we can wrap our property source as with:
> (TransactionalEditingDomain) getEditingDomain(), adapterFactory));
> Are there cases where this isn't enough?
> The reason for asking is that we are aiming at implementing a more
> lightweight threadsafe approach where we do not need to support editing
> domains, commands etc and thus do not want to hook into the whole EMF
> Transactions framework.
> Thanks for all input!
Powered by FUDForum
. Page generated in 0.03139 seconds