Home » Modeling » EMF » CDO Transaction conflicts – not possible to add two object at same time by two transactions!?
| CDO Transaction conflicts – not possible to add two object at same time by two transactions!? [message #558873] |
Tue, 14 September 2010 16:59  |
Eclipse User |
|
|
|
Originally posted by: guen.my-lounge.net
Hi,
I have a really big problem here, cause I’am using CDO in a
WebApplication with many Clients and I’am getting a lot of transaction
conflicts. To get a foucs on my problem I wrote this test below, which
opens two transactions (for each ‘client’ one) and add a new Object –
the second committ fails cause of resource conflict! How could that be –
these are two new different Objects, which don’t have any relationship!?
I guess that happends cause they got the same temporary CDO ID in the
resource – but is that right?
// create two simple objects
SimpleClass simpleObject1 = SimpleFactory.eINSTANCE.createSimpleClass();
simpleObject1.setIntAttribute( 1 );
simpleObject1.setStringAttribute( "text for 1" );
SimpleClass simpleObject2 = SimpleFactory.eINSTANCE.createSimpleClass();
simpleObject2.setIntAttribute( 2 );
simpleObject2.setStringAttribute( "text for 2" );
// get same resource twice, to simulate two "clients"
CDOTransaction transaction1 = cdoSession.openTransaction();
Resource resource1 = transaction1.getResource( RES_SIMPLE_CLASS );
CDOTransaction transaction2 = cdoSession.openTransaction();
Resource resource2 = transaction2.getResource( RES_SIMPLE_CLASS );
// each "client" is adding the his object
resource1.getContents().add( simpleObject1 );
resource2.getContents().add( simpleObject2 );
// each "client" commits - second commit fails!!!
transaction1.commit();
transaction2.commit();
By the way, the value of transaction2.hasConflict() is false – is it a bug?
Big Thanks for any help or workaround – otherwise I have to spend some
long nights to leave CDO and switch to Eclipse Link, Teneo, pure
Hibernate or something like that
greetz and thanks,
guen
|
|
|
| Re: CDO Transaction conflicts – not possible to add two object at same time by two transactions!? [message #558899 is a reply to message #558873] |
Tue, 14 September 2010 19:26  |
 Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
comments below...
Am 14.09.2010 18:59, schrieb Christian Guenther:
> Hi,
>
> I have a really big problem here, cause I’am using CDO in a
> WebApplication with many Clients and I’am getting a lot of transaction
> conflicts. To get a foucs on my problem I wrote this test below, which
> opens two transactions (for each ‘client’ one) and add a new Object –
> the second committ fails cause of resource conflict! How could that be –
> these are two new different Objects, which don’t have any relationship!?
> I guess that happends cause they got the same temporary CDO ID in the
> resource – but is that right?
>
>
> // create two simple objects
> SimpleClass simpleObject1 = SimpleFactory.eINSTANCE.createSimpleClass();
> simpleObject1.setIntAttribute( 1 );
> simpleObject1.setStringAttribute( "text for 1" );
>
> SimpleClass simpleObject2 = SimpleFactory.eINSTANCE.createSimpleClass();
> simpleObject2.setIntAttribute( 2 );
> simpleObject2.setStringAttribute( "text for 2" );
>
> // get same resource twice, to simulate two "clients"
> CDOTransaction transaction1 = cdoSession.openTransaction();
> Resource resource1 = transaction1.getResource( RES_SIMPLE_CLASS );
>
> CDOTransaction transaction2 = cdoSession.openTransaction();
> Resource resource2 = transaction2.getResource( RES_SIMPLE_CLASS );
>
> // each "client" is adding the his object
> resource1.getContents().add( simpleObject1 );
> resource2.getContents().add( simpleObject2 );
>
> // each "client" commits - second commit fails!!!
> transaction1.commit();
> transaction2.commit();
>
I would say that this is a simple conflict. You modified the same
version of the resource in two different transactions. So the second
transaction must fail. The objects (SimpleObject) are not related but
they are added to the same list (getContents()). In other words: the
resource is in conflict, not the objects.
>
> By the way, the value of transaction2.hasConflict() is false – is it a bug?
>
> Big Thanks for any help or workaround –
If you are sure that the objects you added to the content of the
resource are different from each other, you could have a look at CDO's
conflict resolvers. So the conflict on transaction2 can be automatically
resolved before you commit.
otherwise I have to spend some
> long nights to leave CDO and switch to Eclipse Link, Teneo, pure
> Hibernate or something like that
You better don't do that ;)
Cheers,
Martin
>
> greetz and thanks,
> guen
|
|
|
| Re: CDO Transaction conflicts – not possible to add two object at same time by two transactions!? [message #558931 is a reply to message #558899] |
Tue, 14 September 2010 22:28 |
| Eclipse User |
|
|
|
Originally posted by: guen.my-lounge.net
Hi Martin,
thanks for your quick response!!! Helps me much to understand CDO better :-)
.... so to avoid conflicts
a1.
it makes no sense to open more than one transaction for a resource at a
time - for create and remove ... update is working with more transactions?
a2.
it makes no sense to seperate "add/remove from resource" and "commit",
also the code block "add/remove resource -> commit" should be syncronized?
a3.
but it makes sense to use a new transaction for every create and remove
to get a rollback for it ... or is the creation of transactions to
expensive?
b1.
cause commit is very expensive, another way is to handle all requests
with one transaction for the resource all the time - to avoid committing
every time ... is this the better solution?
I'am asking in detail, cause of performance issues - if more than 100
user request come in at the same time, it takes a while to create the
respone (e.g. to create new CDO Objects and commit; maybe some test data
is interesting - e.g. I tested to create and commit (syncronized) a
simple object (no relations) via 100 Threads on the same time and each
Thread was creating 10 Objects. Thread number 100 had to wait 19:813
seconds:milliseconds on Intel T2500,2GHz,2GB Ram,MySQL)
thanks and greetz,
guen
Martin Flügge schrieb:
> Hi Christian,
>
> comments below...
>
> Am 14.09.2010 18:59, schrieb Christian Guenther:
>> Hi,
>>
>> I have a really big problem here, cause I’am using CDO in a
>> WebApplication with many Clients and I’am getting a lot of transaction
>> conflicts. To get a foucs on my problem I wrote this test below, which
>> opens two transactions (for each ‘client’ one) and add a new Object –
>> the second committ fails cause of resource conflict! How could that be –
>> these are two new different Objects, which don’t have any relationship!?
>> I guess that happends cause they got the same temporary CDO ID in the
>> resource – but is that right?
>>
>>
>> // create two simple objects
>> SimpleClass simpleObject1 = SimpleFactory.eINSTANCE.createSimpleClass();
>> simpleObject1.setIntAttribute( 1 );
>> simpleObject1.setStringAttribute( "text for 1" );
>>
>> SimpleClass simpleObject2 = SimpleFactory.eINSTANCE.createSimpleClass();
>> simpleObject2.setIntAttribute( 2 );
>> simpleObject2.setStringAttribute( "text for 2" );
>>
>> // get same resource twice, to simulate two "clients"
>> CDOTransaction transaction1 = cdoSession.openTransaction();
>> Resource resource1 = transaction1.getResource( RES_SIMPLE_CLASS );
>>
>> CDOTransaction transaction2 = cdoSession.openTransaction();
>> Resource resource2 = transaction2.getResource( RES_SIMPLE_CLASS );
>>
>> // each "client" is adding the his object
>> resource1.getContents().add( simpleObject1 );
>> resource2.getContents().add( simpleObject2 );
>>
>> // each "client" commits - second commit fails!!!
>> transaction1.commit();
>> transaction2.commit();
>>
>
> I would say that this is a simple conflict. You modified the same
> version of the resource in two different transactions. So the second
> transaction must fail. The objects (SimpleObject) are not related but
> they are added to the same list (getContents()). In other words: the
> resource is in conflict, not the objects.
>
>> By the way, the value of transaction2.hasConflict() is false – is it a bug?
>>
>
>> Big Thanks for any help or workaround –
>
> If you are sure that the objects you added to the content of the
> resource are different from each other, you could have a look at CDO's
> conflict resolvers. So the conflict on transaction2 can be automatically
> resolved before you commit.
>
> otherwise I have to spend some
>> long nights to leave CDO and switch to Eclipse Link, Teneo, pure
>> Hibernate or something like that
>
> You better don't do that ;)
>
> Cheers,
>
> Martin
>
>> greetz and thanks,
>> guen
>
|
|
|
| Re: CDO Transaction conflicts – not possible to add two object at same time by two transactions!? [message #558945 is a reply to message #558931] |
Wed, 15 September 2010 05:41 |
|
This is a multi-part message in MIME format.
--------------090008070104030706010001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Christian,
Comments below...
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
I'm speaking at Eclipse Summit Europe 2010 <http://www.eclipsesummit.org/>
Am 15.09.2010 00:28, schrieb Christian Guenther:
> Hi Martin,
>
> thanks for your quick response!!! Helps me much to understand CDO better :-)
>
> .... so to avoid conflicts
>
> a1.
> it makes no sense to open more than one transaction for a resource at a time - for create and remove ... update is working with more transactions?
Note that the locking granule is not a resource! Rather it is each single object and resources are also normal single objects in this regard. In your case it just happened that the conflict occured on the resource object directly. So, in general, it does make a lot of sense to isolate multiple threads operating on the same resource with multiple transactions. It just doesn't help if the exact same object is modified by two or more transactions.
>
> a2.
> it makes no sense to seperate "add/remove from resource" and "commit", also the code block "add/remove resource -> commit" should be syncronized?
What do you mean by synchronized? As long as you're using separate transactions it is absolutely ensured that no data (object) in the repository is corrupted by conccurrent modification. Of course this does not prevent conflicts from being detected and rejected in the server if the same object is modified concurrently (see above). This situation can be dealt with differently:
1) Use your own pessimistic locking, e.g. Java locks or synchronized blocks if the client transactions all run in the same VM (as in a web container), or some sort of networked registry if multiple VMs are invloved.
2) Use CDO pessimistic locking:
CDOObject.cdoReadLock().lock(...);
CDOObject.cdoWriteLock().lock(...);
CDOView.lockObjects(Collection<? extends CDOObject>, LockType, long)
CDOView.unlockObjects(Collection<? extends CDOObject>, LockType)
CDOView.unlockObjects()
3) Use CDOConflictResolvers at client side:
CDOTransaction.Options.addConflictResolver(CDOConflictResolv er)
with e.g. new CDOMergingConflictResolver(CDOMerger)
and e.g. new DefaultCDOMerger.PerFeature.ManyValued()
Note that client side conflicts resolvers may always be a little bit behind reality due to network latency. Hence conflicts may still occur on the server during commit.
In the team we've also discussed the usage of conflict resolvers on the server. But the current design of the CDOProtocol does not allow for "changes to changes" on the server while the latter are being committed to the server. There's currently no mechanism to reflect these "add-on changes" back to the committing client.
>
> a3.
> but it makes sense to use a new transaction for every create and remove to get a rollback for it ... or is the creation of transactions to expensive?
CDOViews and CDOTranactions are cheap on the server. The server knows that they exist on the client (yes, opening and closing a view/tx involves a single server request/response each) but nothing more.
On the client side a CDOTransaction occupies the same space as a CDOView as long as the transaction is clean. Modifying objects in a transaction remembers change deltas and new objects and CDOIDs of deleted objects *per CDOSavepoint* where the modification occured plus a copy of each changed object with the new state *per CDOTransaction*.
Note that the data of clean objects is shared among all views/transactions of the same CDOSession.
>
> b1.
> cause commit is very expensive, another way is to handle all requests with one transaction for the resource all the time - to avoid committing every time ... is this the better solution?
I doubt it. Whether commit is expensive or not depends on many things, most notably the versioning mode of the repository. Are you using the AUDITING mode? That would lead to performance decrease especially if you're committing changes to huge many-valued features (lists). On almost all levels of CDO we're offering reasonable optimization options. Have you already found http://wiki.eclipse.org/Tweaking_CDO_Performance ?
>
> I'am asking in detail, cause of performance issues - if more than 100 user request come in at the same time, it takes a while to create the respone (e.g. to create new CDO Objects and commit; maybe some test data is interesting - e.g. I tested to create and commit (syncronized) a simple object (no relations) via 100 Threads on the same time and each Thread was creating 10 Objects. Thread number 100 had to wait 19:813 seconds:milliseconds on Intel T2500,2GHz,2GB Ram,MySQL)
Without knowing all details about the test model used, the test logic executed the client and server options configured, etc.. it's evry hard to extract real value from these numbers ;-)
With your description, the mention of "synchronized" in particular, I suspect that most of the time your threads have been waiting in monitor lock contention. Not CDO-related at all. Depending on how exactly you've set up your scenario this could mean that each commit took only 20seconds / 100 threads = 200 milliseconds. Not too bad, I'd say.
--------------090008070104030706010001
Content-Type: multipart/related;
boundary="------------050504060903080408060802"
--------------050504060903080408060802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Christian,<br>
<br>
Comments below...<br>
<br>
<!--WISESTAMP_SIG_54391_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers<br>
/Eike<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.01070006.08010209@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.01040800.04080404@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.09010207.01050207@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.01050103.07020205@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
<div><br>
<a href="http://www.eclipsesummit.org/"><img
src="cid:part5.09060009.06030403@esc-net.de" alt="I'm
speaking at Eclipse Summit Europe 2010" border="0"
height="100" width="100"></a>
<br>
<br>
</div>
</div>
</span><!--WISESTAMP_SIG_54391_END--><br>
<br>
Am 15.09.2010 00:28, schrieb Christian Guenther:
<blockquote cite="mid:i6osua$otk$1@build.eclipse.org" type="cite">Hi
Martin,
<br>
<br>
thanks for your quick response!!! Helps me much to understand CDO
better :-)
<br>
<br>
.... so to avoid conflicts
<br>
<br>
a1.
<br>
it makes no sense to open more than one transaction for a resource
at a time - for create and remove ... update is working with more
transactions?
<br>
</blockquote>
Note that the locking granule is not a resource! Rather it is each
single object and resources are also normal single objects in this
regard. In your case it just happened that the conflict occured on
the resource object directly. So, in general, it does make a lot of
sense to isolate multiple threads operating on the same resource
with multiple transactions. It just doesn't help if the exact same
object is modified by two or more transactions.<br>
<br>
<blockquote cite="mid:i6osua$otk$1@build.eclipse.org" type="cite">
<br>
a2.
<br>
it makes no sense to seperate "add/remove from resource" and
"commit", also the code block "add/remove resource -> commit"
should be syncronized?
<br>
</blockquote>
What do you mean by synchronized? As long as you're using separate
transactions it is absolutely ensured that no data (object) in the
repository is corrupted by conccurrent modification. Of course this
does not prevent conflicts from being detected and rejected in the
server if the same object is modified concurrently (see above). This
situation can be dealt with differently:<br>
<br>
1) Use your own pessimistic locking, e.g. Java locks or synchronized
blocks if the client transactions all run in the same VM (as in a
web container), or some sort of networked registry if multiple VMs
are invloved.<br>
<br>
2) Use CDO pessimistic locking: <br>
<br>
CDOObject.cdoReadLock().lock(...);<br>
CDOObject.cdoWriteLock().lock(...);<br>
CDOView.lockObjects(Collection<? extends CDOObject>,
LockType, long)<br>
CDOView.unlockObjects(Collection<? extends CDOObject>,
LockType)<br>
CDOView.unlockObjects()<br>
<br>
3) Use CDOConflictResolvers at client side:<br>
<br>
CDOTransaction.Options.addConflictResolver(CDOConflictResolv er) <br>
with e.g. new CDOMergingConflictResolver(CDOMerger)<br>
and e.g. new DefaultCDOMerger.PerFeature.ManyValued()<br>
<br>
Note that client side conflicts resolvers may always be a little bit
behind reality due to network latency. Hence conflicts may still
occur on the server during commit.<br>
<br>
In the team we've also discussed the usage of conflict resolvers on
the server. But the current design of the CDOProtocol does not allow
for "changes to changes" on the server while the latter are being
committed to the server. There's currently no mechanism to reflect
these "add-on changes" back to the committing client.<br>
<br>
<blockquote cite="mid:i6osua$otk$1@build.eclipse.org" type="cite">
<br>
a3.
<br>
but it makes sense to use a new transaction for every create and
remove to get a rollback for it ... or is the creation of
transactions to expensive?
<br>
</blockquote>
CDOViews and CDOTranactions are cheap on the server. The server
knows that they exist on the client (yes, opening and closing a
view/tx involves a single server request/response each) but nothing
more.<br>
<br>
On the client side a CDOTransaction occupies the same space as a
CDOView as long as the transaction is clean. Modifying objects in a
transaction remembers change deltas and new objects and CDOIDs of
deleted objects *per CDOSavepoint* where the modification occured
plus a copy of each changed object with the new state *per
CDOTransaction*.<br>
<br>
Note that the data of clean objects is shared among all
views/transactions of the same CDOSession.<br>
<br>
<blockquote cite="mid:i6osua$otk$1@build.eclipse.org" type="cite">
<br>
b1.
<br>
cause commit is very expensive, another way is to handle all
requests with one transaction for the resource all the time - to
avoid committing every time ... is this the better solution?
<br>
</blockquote>
I doubt it. Whether commit is expensive or not depends on many
things, most notably the versioning mode of the repository. Are you
using the AUDITING mode? That would lead to performance decrease
especially if you're committing changes to huge many-valued features
(lists). On almost all levels of CDO we're offering reasonable
optimization options. Have you already found
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Tweaking_CDO_Performance">http://wiki.eclipse.org/Tweaking_CDO_Performance</a> ?<br>
<br>
<blockquote cite="mid:i6osua$otk$1@build.eclipse.org" type="cite">
<br>
I'am asking in detail, cause of performance issues - if more than
100 user request come in at the same time, it takes a while to
create the respone (e.g. to create new CDO Objects and commit;
maybe some test data is interesting - e.g. I tested to create and
commit (syncronized) a simple object (no relations) via 100
Threads on the same time and each Thread was creating 10 Objects.
Thread number 100 had to wait 19:813 seconds:milliseconds on Intel
T2500,2GHz,2GB Ram,MySQL)
<br>
</blockquote>
Without knowing all details about the test model used, the test
logic executed the client and server options configured, etc.. it's
evry hard to extract real value from these numbers ;-)<br>
<br>
With your description, the mention of "synchronized" in particular,
I suspect that most of the time your threads have been waiting in
monitor lock contention. Not CDO-related at all. Depending on how
exactly you've set up your scenario this could mean that each
commit took only 20seconds / 100 threads = 200 milliseconds. Not
too bad, I'd say.<br>
<br>
<br>
</body>
</html>
--------------050504060903080408060802
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.01070006.08010209@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------050504060903080408060802
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.01040800.04080404@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------050504060903080408060802
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.09010207.01050207@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------050504060903080408060802
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.01050103.07020205@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------050504060903080408060802
Content-Type: image/gif;
name="100x100_speaking.gif"
Content-Transfer-Encoding: base64
Content-ID: <part5.09060009.06030403@esc-net.de>
Content-Disposition: inline;
filename="100x100_speaking.gif"
R0lGODlhZABkAOZ/APb3+VNYfigtUDRDchhWpwM6mkRXjThrsCdirVJ7u0p2 uExflWyGrQU0
asnX6aq31ImZUxRFoaOqOWaIwgRGlubr87bG4C44YMHDzmeGZYqMrtLRFuHi 5zpalGxskRZD
lVt/vdHZ6TRlqzlTiJiy1Wd7qExtrB00XDtfnH2SvyFeq0ZttQlTo9vi7lNt qTRfryVJlkVr
rXmEkYebxLKzvPDqAi9ZrANMniZGgTpMfh4dNSpWk4OjywI6flx0qIV2rDxk pD5psQNBiyw8
jjpksJSkx4OImhtFi2CEv0NjornAMCBRoYqq0uvw9zNor4SBRj5xtcbGHr65 HDRhoxVPoyRR
pypWqg0/nB5aqSE+bUU/kCpQh1NRKildo05ppUBnqh1LpJOt0ZecsaCJwkRH aU5yozRMmGpY
nz5sgk9knmyPw6alwDk+YNPT3uLdCkVop2BggnaOvC1lrre5TBc7fVB7fRFP lRtakkNfmnyc
yypVnyxdrcTQ5O/v8v///////yH5BAEAAH8ALAAAAABkAGQAAAf/gH+Cg4SF hoeIiYqLjI2O
j5CRkpOUlYp+mE2amhUOm5uYfpajpIiZfHl5SKsgra4gCbEJamopFU2YpbqT fk0OeRPBq6yv
ssYJCskKSGoVubvQpn6/wcLErsexysor3d1BzaLR471M1dZI2LLb297u30Hx CRbi46Tl5xPX
6+3v7vEAARIZSOQFPXuVevHIl66VtmTvAhKcSHHii4sXbRxECMkPn3P7IHqL RxGjyZMoTdpY
ScQZR0bTQDZ8CG8gxpU4rejcydMKzp9AdyYA8DKRx2rEtI20+WLlzipQo0qd GrWnVagvKhQ1
5EcNUofIvjG1oVMqmLNo06pNS7Ut1I1F/2Nac6hAbMayVdJG2Mu3r9++a8FQ TauA6Eu5+ujW
DWKTLFS9fq9Inkz5yt+9gTNbMWxPbtK6Kxg3tfL4bN/KqFNTvpwZzN4qnKHF HAYrrOgXZdHy
TV2gt+/fv1VfHg472uyZoEU7zut6L2rg0KP7Tj38NJjYozzTtevYtPPn0sNH Fx558nVdDoal
C7ui4B7SzHerliy+fvD5lQuAqVcJAG1YixXk2BLNRYDaBwgmSJ99DOK3YAFh ZKfGZ918UcaA
BRooWYIfwGDGhzDA8MEVDJZYAG/APZCQBRSuUIYESqDBXHOoDeFhB0nkiIIe H2qhxQAXBHlB
FnSYCB1l0mH3SP96DTEgAQRlBPGFEkpMAcYSGUCwQ2oe4uGFDyWAUMIPP5wR ABlksCGkAAKc
UKSRJUagJEy0JcCAG1GUcREKU+hxpQRujHAgDHqkUUIKRayxhgYewHFmmkJe wGabcJYYYUcs
zpSADDIISJppaKABw6Ao+JDCAyG0QQOjjqKp5pqTClApg3Mm0gQxDAT4wnvx yQcDDpN1mIQP
M7RRQQir/tBqmmoKICmbOlA6q3h6POKHKiAwMIcSMoTmXhUEZnjFDk9u8YGN ZqDgQhEYtIHB
oo0+yoYAHtAwKRlGSPrmtNK14MitDSmxQQmi8UrgX0tEsYGB537owhiKiqHB Dx48mqb/ADJU
MGkAbbARLb/SXQEEf6Zg2woDJURJxHtWhHvZDjtoeAUMaZA5McUVe+ABGRfM KwMH0U6qw9BZ
9HbFEiQGRyB0FCyBdGr+LtKEOgGKsCt84YJBxdZUnJZEqhW00WijcGBQAQcV GMHmz0FzfEG0
bFiQAh99tNBB0kCEoDcfo/a2BB98hGDBqJWNfEke2ICQHGMFpXTSG3uYUEEa A+QQwho5wLFA
G23w7IEMPRvBgbNseAAAGQKwQQYADxiQwxoV4HAEDE2UkEUOJRhwRIchlIAD DuzuTpkQHFwy
gUPaQqAA4xjt4fzz0E9RhwRoFGHBCDq3ewEZpgegw7NBiu7s/wVw9DGvAGT0 sUAWOIwAwAJ0
wOBHCjngQIfsV7zBwQJpdOADACMQ3hWEIIQiGMUC2GBADeawggMQwWrQi2DL QvSEGsDhARzA
AB84JwZnlaAPkmKDCNUkPmeV71npSwMOEFQBH6zQCxXoAwcYILwSAAADGHiA DgOIIAIKoQd9
MMXxamMngjHGalZ7gQiWSJAk2qAMJRgBCWhwghwEIAfOGoDpUEeGHFRuAOIL UvnmtT31rVAP
75PdEXCwAA34oQS78wEHBvC7Ou7uAwTsQQ/4gAgAEDEZUIiHEy4SwUJCzwoR cIEfFqCFM1Cs
Z2SowBqixT01/WxSJ4RbH3xAhw+koP8FslvCFD5AhyNUQAOdRKMGZAeDJIho RHnsAQoO4ZHa
cCMIBxCBHAxpyClYKUQa6EMIWgCANaSOfBzgQBv60EEBlFAA5ROAJpXJgRYs gJUtCMED3FU/
EcGQDw8Ap4gG+EM9HiGIhfDDBPgBhRhk6Q0qwAIB5jlPp3Fta3rIQAYIdC4D lIBR58PkzoaW
OjIQFH1Di1YLSsDQEciOAhSAgQ8Y4ILfwWBrYBhBCShavyOQU496bANX1qkN KEChDFFwQx3i
KU96zvOeVEDBBtywAzDAYAhDuEAjzxBQaSZUaEHzKdEmV8ojHAGiEP2AUUN0 T5vaEY+x1KMB
C9EEdkLhAPr/BAJLXcrVeWIhA3VYwk1xOgQtkAkOz4qVWmOVUB184AELOCpS KXADukYAplQg
wD0RRIGompM/HmHnAZwgBwTsQQVdwEJLu9oFeoo1RCHKQSPH8APUrfWybaUD BT7wULre4LOg
helLuRYBiPq1B+ckhB+Q8BCTDnaXKkDDk6bgVXp2AQLUsykMwjUCCUghCnA4 A2Ute1mgDu0E
c6UABOoAWtCygGsuvadpT7tH1aqhtVclLAJUAIQNRKGxXahDBsALKAM4jQBY cBoEpGAGOMDB
rMNV6/k81tYLfGCzdb1BBtCgXwncgQXPzStXuWaH6ZYTpD0Q6SDUid3Xbje8 dZAn/woUhgbF
hiqxik3vEiCwgRGUVQtSgMAP5iABATwhClLYgG/d8IShSeG3T9qAEuxwAwnU 4Q4z9e/WuqrX
rdW1r6dtgBgIUQFjKMC12lUBSzOcJQxn+MnpJVcNnuCjDVBZCXM4AwRqwIUK djkKOmBDDTKw
hTHfoQb83UAGbgABJdxhxzzm2o99iOAGNIAO9aiqYJO8ZCj7GcpVgEEGpmyG KFBZAhLQAgSi
MIQnSMHEUhjCFtxwBDu4ga5ovkEU1tzm59Izw/T08Zz9auct5JkfR3bwdv+s 2Hj2maV6gAEY
1msGK2shCok+sRYc3WgpfGDSlXbDHSzN302zWQks+DSoX//Kgh8D+cA9sDMO Tv2QVKu6z09W
srZdrVgIQCADbsgADCSg4hpAoNGMPvEH1F3mSqP5Dm5IcwZYAG4INBbKof4s UukMUmlTGxlH
vuq1sY2FbRscC3pAw7fRoIcqjCADjgoADAwg8REE4Ncj+IAd+HuDOtiBBR7v +H/pnQF54rvH
oDVwv/09iCI3+LWF3a6Ss61tBNgcsXqwwratEOvdPhayr9zLxwHcXOcCONle LfhW9dpsfQO5
ztLmDB8ADkiBEzbmMjd4zW3eBT104eba7jrP9aAHp5n9nkc/etHTnnRtK3ae RHc2qe1MB3T+
oQnsMGl2tWvzrGu973rYQ98H34X/Lmz7yVxNu9o/y3b0Kn3mLY37vqFt5wZs gRB434beB3v1
wWtdBX3vguDlQHrSc33wfl86PRXPeq9qPfJNH/XKWS6IzFcdyYRVAAkUgPqt I0D0pQ8+1lEP
dpaCgAmrlwMTENB69L5enpKf7uwbMO1B2D7gSPYDCSagTuITHgHCl4MTrl56 8BNf20zwg0sT
4AcFKL7tSs469GMvfT1Wnvr1qIAy9C7wA2hfDn5get7Xd8I3fgY4fuE3fCoQ Bn7wdnDXfI9X
fPMHWnyQAlF1f9VXe9i3eQfgfyQgBx/oAA5ADxaQB37QAgdgc6THBADgBxXg BCTgBzzgggng
BDzgDBZA/3oOgAl8cAAMqAJ50AIIwH4JwALat4NqgAVysIMOAABhIHNYQAIt GAIHMIMeUU73
1wAjUA+rxX+uNVj/p4MAkAd8oH0xOAHgR3p+kIMKAIPaZ4IWAAUAwARQ0BVy AAJyoAarxYAJ
UAFQgAVEaIT+0QlYwIKxoH03hwUKQAAqIIM3IIOxlIUYUAhI4IUdCIYfqIMO AIIByH0TEHx5
UAEtkAdu2IEiqIehQAJQQA+YMAExCAB8EE8g4AdF6AdMwAIiiAUiCHqIKHMs iAk88Ig8cGCS
WAhqwH+XiIlXJ4KcKAeeGH4xCAIxeFUVYAHsxwQGmH4g4IkxaII8oAKzmAAE YP+LuOgAWGAB
AOAESNCLQyiD4xiMkDh9DTCJRIaMl+gE2reMmxiDzqhOwdcJoggFMcgHFQAA CXAAMSiC23eC
ZWgB/EgPq+AHIDCOyCeCBLCOa8iOTgAA1ciRFBACTfAA9nd/WYAdTdB/9+gE aqAApdcKcqAA
nwgFE3AAwQeTEzB+07iSlzgLajB+CYAE6ogEMEl666SOcgCITkAAULCIcgAF lXgtAugEE+kE
ClBgZbADI1l5OYAdtJiMHXiATrBES5SAwrdEOOkHXpmMB8h5CBh8q9ZVhdGE KCiAhpdedlBg
kXh/NHAIapCSYKlLYikHupSAYikCPtmXHRgPXjl+ann/gOW3ZJ8mB6ylgnRp l3iZlZVHj4XQ
AgdomGEZloUZmtsnAqNZmAZ4iQGhmGn5lZ85mDFHcPGXhoW1B12ABGGwBHZw BFh4fycwJ34A
BaG5RKGgfcFJnMRpmk5wALiknKnplTfoB/5hgGNZfnWZYTUXfLTJgDsAA0ZF B9F2f0ZAMoMw
AcEpAsdZnucZnInJnKmZmrAYBKx1iUs0eqRHm68Wm4I5BYWnBztQBnxQBnSQ hfOYCBWAniRQ
mEzgDAVqnAeqN/QQAvHAihYQBBPQAn4QAiAQEKKoBvGgh2pABNq3ByJIgibY ApIpgwDgHxaa
B1OgnWXoBzMQoFpZK4IQA77k/0vCGQoioIdMIAIJYJ4HSpwhAAA8EIM8oIc8 EAQZGgJ8EAMt
8AABgQQ4qAAeGgTaNwVNSIbax4ARaQF62ALN4ABdoJ0l4Ac+kAVZcAKVt5eK 8AA3eqPaBwRy
GoNyCgRACqR5EwJf8AXa9wUPAItqEAPDGQIxUKjxEAMM6KVdYaUHKoJdEIMi wH0RiQRd4Adh
0AWOyoBbUKZnmqYnoKbFcwlv6ktxKqcz0BV1Gqd9OkxfwH488AUxoAB8AAAx UAFNWqi4GquF
2gJ8oId5MIMkQASZ6gc7qk6SWqmXKoI7oKk+YKZo+qknIAON4KYowCco4IIO oE15c6EVMDIk
4K1fEP8CxwIALfAFapBNAGABMZAH5MqkuXqhxHQ8LUgPJBCuIdCindgVekip lqoHyloEfrAF
C9AHp+SpJxCqiwAA1bqwDNCwDAACcgoCauADQHBd5poA9poAcbCnXzABcTAB uJoAKRAHCWAC
uKoAcRAHuLqNMWCxqwAECTABUwAO3RCoU4AEMaAHZVAGW4AHLoQDOeABAwCt 0uoID7CwSIu0
dVqnXwAEe6o3X/AGUvsGuGoCVnu1WFu1MWC1ucqxXgsEUyACRMCxvsSfO7AF W1BHaGqwB/sI
AFAGHZC0Sbu0dZoEb7AKU0u1hYq1fHu1e8u3uOq1HGunTrunQIACHXC2afv/ O2sLrSegAZHA
AR0wuZQbt3Mrp0kABHabt1O7tX3bt54LujEgtYLbtEubBIjbAWjLuM8KrasT CX4At5U7uXKr
uTmyuVIbB8OZAnzrAibgu58LunkruJmLuXjQASMwAmnbuI7LppEAAF4wu5Qr t7eLu7obB17g
BVfrAtzbvcAbvFg7tcSbI3hQrcc7AjngRa0LrUZAo4sgudI7vQtbvVN7vdpr Ag/gBy6QAvOj
SAT5ABMQAtD5APjrBwBbASDgBRV6oRRru0lwvJObvF40AFlwAY7LBu7LCA+Q vByMvJWLAuWL
B7f7Bl6gu5gQAi6Qv/vbvyc4AyUwTD4AsKfiBw9w/6oW4AVMmgRPergLS7kS PMFBAq1soGAJ
4QUcfMSziwdKfLsl7AfY6wUprL/8mwKK9ADcS8NWS8Mq7AJ64wWD2sMRLMED MMZCAq3Oawl9
YABHjMSUq8QinARpYL9QnL8+QA9UTMPca6tewAAGTMcuUI3f9MDV6sM/PMZA EsSf2r66kMZr
zMYd4MZ4EMcnqDdFcKoZeccPkL0zQK4AEAJekL8ECQAl4AUp0K58EMboO8Fk XMbOJJ5o7Drp
mwONbAAG8MhKXMIpGwejjDKm4gP7O8rZ6wNxwADZS8cp4ANekAaR3LB4wMHp a8iHDCvhOQ5p
HMuxvMa0bAB4sADczD9p8P/NaZC94gzO5PzN+UvOC4AHtOzMz0zBFYzIbDLN 9lDN1py+R5zN
BtDN3FzO/MzPwvzN3bzOsQzN7wytkyLPCNEHqVzP9py8+KzPEK3PkBzRAa3G 7bzKFvypsYLQ
HNEHmGPIDC3LI4DP+azPJH3SKA3LqvzOGR0rF0ADrowQawDNYxzSI53SJM3B Of3DqhwpGh0r
ZEDEW9FyqgzNIW3NC33UR23IZfzTG53BHFEBYkDTVK3UVn3RhvwqaSVfMD3U isABcEDVYj3W
ZJ3VIgQra6XIXp2wGBAAZf3WY/wqWh0pWx0rMiDUa83WATBCdN3Xfv3XQVJc d53XknBDYgDY
iE1P18XFJmRAA3hN2JHb1okd2IstXzJAA1AN2Y0AABmkATyD1pU9KapDA5it 2fbA2ThkBGiy
2vMyQiLU2KSdoqbt1Sla25xt2y0427q924UQCAA7
--------------050504060903080408060802--
--------------090008070104030706010001--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:44:50 GMT 2024
Powered by FUDForum. Page generated in 0.02588 seconds |
] 
Search
Help
Register
Login
Home
