Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Thread-safe UML CacheAdapter?
Thread-safe UML CacheAdapter? [message #1110040] Mon, 16 September 2013 05:22 Go to next message
Eclipse User
In our IDE, we encountered deadlocks when a background job as well as
the UI thread are loading a model from the same file (same problem as
described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=332057).
So we enabled the threadLocal option for the CacheAdapter which solved
these issues.

However, we want to load the model in a ProgressMonitorDialog and then
use it in the UI, but that leads to two different CacheAdapter instances
and all inverse cross-references are not resolved in the UI thread.

Any idea how to solve this?
Does anyone know about a thread-safe CacheAdapter which we could use
instead?

Patrick
Re: Thread-safe UML CacheAdapter? [message #1111555 is a reply to message #1110040] Wed, 18 September 2013 07:32 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael Chaves
Messages: 161
Registered: July 2009
Senior Member
I hear you. I really like the UML2 library, but the CacheAdapter is a constant source of sorrow.

I happen to be in the middle of yet another initiative to make UML models using UML2 thread-safe and have decent performance. Basically, I am pairing a UML "repository" (a resource set) with its own copy of a cache adapter, and implementing a pool of repositories. When a thread needs a UML repository, if it is in the pool, it is brought into the current thread (including its cache adapter). When it is done using it, the repository is placed back in the pool (and unbound from the current thread) so other threads/requests can use it, until it is eventually (if it is not used for a while) pushed out of the pool by requests to other repositories.

It should work for my case where I own the entire application and all uses of UML2 models is in my code. But it won't work if third party code may be loading UML2 models as well (without going through the same gatekeeper).




Threadsafe UML+OCL (was Re: Thread-safe UML CacheAdapter?) [message #1111574 is a reply to message #1111555] Wed, 18 September 2013 08:02 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

Can you clarify your use case a bit?

For Luna, we would like to have UML 2.5 support with 'all' the
associated OCL code generated directly to Java rather than just a manual
transcription of the best bits as at present.

My current considerations are focused on a UML+OCL to Ecore+OCL to Java
route, since practical usage of UML models uses Ecore.

This clearly does not align with your CacheAdapter concerns, so perhaps
you can help me understand what (threadsafe) OCL code generation support
you might need.

Regards

Ed Willink

On 18/09/2013 12:32, Rafael Chaves wrote:
> I hear you. I really like the UML2 library, but the CacheAdapter is a
> constant source of sorrow.
> I happen to be in the middle of yet another initiative to make UML
> models using UML2 thread-safe and have decent performance. Basically,
> I am pairing a UML "repository" (a resource set) with its own copy of
> a cache adapter, and implementing a pool of repositories. When a
> thread needs a UML repository, if it is in the pool, it is brought
> into the current thread (including its cache adapter). When it is done
> using it, the repository is placed back in the pool (and unbound from
> the current thread) so other threads/requests can use it, until it is
> eventually (if it is not used for a while) pushed out of the pool by
> requests to other repositories.
>
> It should work for my case where I own the entire application and all
> uses of UML2 models is in my code. But it won't work if third party
> code may be loading UML2 models as well (without going through the
> same gatekeeper).
>
>
>
Re: Thread-safe UML CacheAdapter? [message #1112786 is a reply to message #1111555] Fri, 20 September 2013 02:55 Go to previous messageGo to next message
Eclipse User
Hi Rafael,

thanks for sharing your experience! Unfortunately, we do not have full
control over all clients that use our model :-/

Still, the idea of a centralized CacheAdapter management seems to be
inevitable...

Cheers
Patrick


Am 18.09.2013 13:32, schrieb Rafael Chaves:
> I hear you. I really like the UML2 library, but the CacheAdapter is a
> constant source of sorrow.
> I happen to be in the middle of yet another initiative to make UML
> models using UML2 thread-safe and have decent performance. Basically, I
> am pairing a UML "repository" (a resource set) with its own copy of a
> cache adapter, and implementing a pool of repositories. When a thread
> needs a UML repository, if it is in the pool, it is brought into the
> current thread (including its cache adapter). When it is done using it,
> the repository is placed back in the pool (and unbound from the current
> thread) so other threads/requests can use it, until it is eventually (if
> it is not used for a while) pushed out of the pool by requests to other
> repositories.
>
> It should work for my case where I own the entire application and all
> uses of UML2 models is in my code. But it won't work if third party code
> may be loading UML2 models as well (without going through the same
> gatekeeper).
>
>
>
>
Re: Threadsafe UML+OCL (was Re: Thread-safe UML CacheAdapter?) [message #1112789 is a reply to message #1111574] Fri, 20 September 2013 02:56 Go to previous message
Eclipse User
Hi Ed,

we use a different resource implementation than UMLResource to load a
UML model from another source than XMI. The model loading takes several
seconds up to 1-2 minutes, depending on the model size. This is why we
would like to load the model in a background thread, otherwise the UI
would be blocked. Then, we have the usual use cases to use the model
such as showing it in the default UML Model Editor.

Furthermore, we often process (UML) models in a background thread, e.g.
in a wizard where runnables can be forked.

Cheers
Patrick


Am 18.09.2013 14:02, schrieb Ed Willink:
> Hi
>
> Can you clarify your use case a bit?
>
> For Luna, we would like to have UML 2.5 support with 'all' the
> associated OCL code generated directly to Java rather than just a manual
> transcription of the best bits as at present.
>
> My current considerations are focused on a UML+OCL to Ecore+OCL to Java
> route, since practical usage of UML models uses Ecore.
>
> This clearly does not align with your CacheAdapter concerns, so perhaps
> you can help me understand what (threadsafe) OCL code generation support
> you might need.
>
> Regards
>
> Ed Willink
>
> On 18/09/2013 12:32, Rafael Chaves wrote:
>> I hear you. I really like the UML2 library, but the CacheAdapter is a
>> constant source of sorrow.
>> I happen to be in the middle of yet another initiative to make UML
>> models using UML2 thread-safe and have decent performance. Basically,
>> I am pairing a UML "repository" (a resource set) with its own copy of
>> a cache adapter, and implementing a pool of repositories. When a
>> thread needs a UML repository, if it is in the pool, it is brought
>> into the current thread (including its cache adapter). When it is done
>> using it, the repository is placed back in the pool (and unbound from
>> the current thread) so other threads/requests can use it, until it is
>> eventually (if it is not used for a while) pushed out of the pool by
>> requests to other repositories.
>>
>> It should work for my case where I own the entire application and all
>> uses of UML2 models is in my code. But it won't work if third party
>> code may be loading UML2 models as well (without going through the
>> same gatekeeper).
>>
>>
>>
>
Previous Topic:Package Merge Observation when using Stereotypes/Enumerations
Next Topic:general question about UML Testing Profile
Goto Forum:
  


Current Time: Sat Aug 30 00:33:32 EDT 2014

Powered by FUDForum. Page generated in 0.01950 seconds