You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Tom McCallum <te...@googlemail.com> on 2008/02/05 14:40:26 UTC
Asynchronous problem
Hi Everyone,
Quick question of style really. I have created an app which has a large
amount of interaction between Java and Batik. I do all my
'setAttributeNS' statements in the updatemanager thread, and
'getAttributeNS' statements outside of this thread.
Obviously this leads to some situations where the sub-thread with the
'setAttributeNS' statement has not been completely executed at the time of
the 'getAttributeNS' statement in the java code.
I currently can think of two possible solutions:
Move any code that ever interacts with Batik ( most of my application )
into the Batik UpdateManager thread, effectively making everything
synchronous - kind of against the whole asynchronous-ness of Batik.
The only other way I can think is to store the attributes all locally
before the 'set' statement gets dispatched and make sure the 'get'
statement will retrieve this value and not call 'getAttributeNS', but that
seems like a rather silly option to me.
By the way part of this started because I was merrily setting attributes
and the getAttributeNS was returning 'null', and what was happening was
the liveAttributeValue table had my latest and correct values in, while
the 'attributes' table still had the original basic values in, and the
only thing I can think of is that a thread somewhere is causing the
listener between the two not to fire - any other suggestions?
Any thoughts or comments grateful,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by Archie Cobbs <ar...@dellroad.org>.
On Feb 5, 2008 7:40 AM, Tom McCallum <te...@googlemail.com> wrote:
> Quick question of style really. I have created an app which has a large
> amount of interaction between Java and Batik. I do all my
> 'setAttributeNS' statements in the updatemanager thread, and
> 'getAttributeNS' statements outside of this thread.
>
> Obviously this leads to some situations where the sub-thread with the
> 'setAttributeNS' statement has not been completely executed at the time of
> the 'getAttributeNS' statement in the java code.
>
>
Here's a "quick hack" idea that is gross but may work... put all of your
invocations to setAttributeNS() and getAttributeNS() (in either thread)
inside a synchronized() block (locking the same object of course). This
should at least prevent exceptions thrown in the reader thread and give you
some valid answer, although of course it doesn't eliminate the fact that you
are creating an inherent race condition.
--
Archie L. Cobbs
Re: Asynchronous problem
Posted by Tom McCallum <te...@googlemail.com>.
Glad I am not the only one! At the moment we have delayed the problem by
putting all the major functions in the update manager thread - but it
seems kind of pointless to have the asynchronous architecture and then
have to synchronise everything.
On Tue, 05 Feb 2008 14:25:14 -0000, massimo citterio <ci...@sinapto.net>
wrote:
>
> On Tue, 2008-02-05 at 13:40 +0000, Tom McCallum wrote:
>> Hi Everyone,
>
>> Obviously this leads to some situations where the sub-thread with the
>> 'setAttributeNS' statement has not been completely executed at the time
>> of
>> the 'getAttributeNS' statement in the java code.
>>
>
> I have a similar problem
>
>
>> By the way part of this started because I was merrily setting attributes
>> and the getAttributeNS was returning 'null', and what was happening was
>> the liveAttributeValue table had my latest and correct values in,
>
> is the liveAttributeValue a batik property or yours?
its a batik thing. If you look at the dom.svg.AbstractElement you will
see it set setLiveAttributeValue function.
>
> At the moment, I was looking for a batik method get to know whether the
> svg is ready to be read or not (updating? rendering?), but I haven't
> found anything yet.
Hopefully :)
> I hope to read some answers here.
> bye
>
> Massimo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
--
PS Note this is the new email address - delete term@blueyonder.co.uk as it
won't work soon!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by massimo citterio <ci...@sinapto.net>.
On Tue, 2008-02-05 at 13:40 +0000, Tom McCallum wrote:
> Hi Everyone,
> Obviously this leads to some situations where the sub-thread with the
> 'setAttributeNS' statement has not been completely executed at the time of
> the 'getAttributeNS' statement in the java code.
>
I have a similar problem
> By the way part of this started because I was merrily setting attributes
> and the getAttributeNS was returning 'null', and what was happening was
> the liveAttributeValue table had my latest and correct values in,
is the liveAttributeValue a batik property or yours?
At the moment, I was looking for a batik method get to know whether the
svg is ready to be read or not (updating? rendering?), but I haven't
found anything yet.
I hope to read some answers here.
bye
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by cmckay <ca...@couchware.ca>.
>From what I understand, you should always synchronize your writes *and* your
reads.
The reasoning behind this is that very rarely is a write an atomic
operation. As a result, if you read in the middle of a write, you have a
chance of fetching an object in an inconsistent state.
-Cameron
Tom McCallum-4 wrote:
>
> Hi Everyone,
>
> Quick question of style really. I have created an app which has a large
> amount of interaction between Java and Batik. I do all my
> 'setAttributeNS' statements in the updatemanager thread, and
> 'getAttributeNS' statements outside of this thread.
>
> Obviously this leads to some situations where the sub-thread with the
> 'setAttributeNS' statement has not been completely executed at the time of
> the 'getAttributeNS' statement in the java code.
>
> I currently can think of two possible solutions:
>
> Move any code that ever interacts with Batik ( most of my application )
> into the Batik UpdateManager thread, effectively making everything
> synchronous - kind of against the whole asynchronous-ness of Batik.
>
> The only other way I can think is to store the attributes all locally
> before the 'set' statement gets dispatched and make sure the 'get'
> statement will retrieve this value and not call 'getAttributeNS', but that
> seems like a rather silly option to me.
>
> By the way part of this started because I was merrily setting attributes
> and the getAttributeNS was returning 'null', and what was happening was
> the liveAttributeValue table had my latest and correct values in, while
> the 'attributes' table still had the original basic values in, and the
> only thing I can think of is that a thread somewhere is causing the
> listener between the two not to fire - any other suggestions?
>
>
> Any thoughts or comments grateful,
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Asynchronous-problem-tp15290808p15744409.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by Luca Piccarreta <lu...@gmail.com>.
Hi Tom,
no I'm not calling any fireDOMModification.
The document, the one that is going to be loaded from disk, saved to
disk (remember,
it's an editor!), is just an Apache Document.
A root EditPart listens for DOM events on the Apache Document.
When a DOMNodeInserted event is detected, two objects are created, one
is an EditPart,
another one is the ViewPart. The ViewPart is the SVG Node. The EditPart
is a simple object
that does again the same job of the rooteditpart. It listens for
Mutation Events on its own Apache Node.
and creates child editparts and child viewparts when necessary.
When an EditPart sees that its own Viewpart has fired a
DOMAttributeChanged, it simply calls
setAttribute for the view element (but in the Batik thread).
When an EditPart sees that a child of the document is deleted, it
deletes also the corresponding
child editpart, and the corresponding viewPart.
So... the view is synchronized to the document.
But the document is not synchronized to the view. That might be much
more difficult to implement.
Just look at it as unidirectional synchronization.
Ciao,
Luca.
Tom McCallum ha scritto:
> Thanks for your reply, interesting approach.
>
> What you are saying is that instead of using the get/setAttribute
> routines you call the fireDOMModification... functions instead? If my
> understanding of batik is correct what you have effectively done is to
> turn it into a synchronous update model.
>
> (1) what is the performance like when you do this?
>
> (2) Are there any problems you can tell us about to avoid?
>
> (3) Are you saying that your way you cannot run any Rhino Javascript
> functionality?
>
> Thanks for your reply - most informative.
>
> Tom
>
>
> On Tue, 05 Feb 2008 15:51:01 -0000, Luca Piccarreta
> <lu...@gmail.com> wrote:
>
>> Hi Tom,
>> I'm developing an SVG editor. And... I can't imagine many scenarios
>> in which
>> bidirectional interaction is so frequent with the SVG document.
>> The best solution I found was an MVC approach, in which the document is
>> a simple Apache DOM document, the view is a Batik Document, and the
>> controller is a hierarchy of objects that forward DOM Mutation Events to
>> the Batik Document.
>> This way you can set and query attributes on the Apache Document without
>> worrying about threads and queues and whatever.
>> Mouse events are also dispatched through the controller hierarchy
>> (they are
>> captured and forwarded to the GUI main thread, SWT in my case).
>> It cost me a couple of weeks of work, but now the code is so much
>> cleaner.
>> On the other hand this approach is not feasible if the Batik document
>> runs
>> any sort of scripts (the whole stuff works if the view is not... self
>> modifying)
>> Best of luck,
>> Luca.
>>
>> Tom McCallum ha scritto:
>>> Hi Everyone,
>>>
>>> Quick question of style really. I have created an app which has a
>>> large amount of interaction between Java and Batik. I do all my
>>> 'setAttributeNS' statements in the updatemanager thread, and
>>> 'getAttributeNS' statements outside of this thread.
>>>
>>> Obviously this leads to some situations where the sub-thread with
>>> the 'setAttributeNS' statement has not been completely executed at
>>> the time of the 'getAttributeNS' statement in the java code.
>>>
>>> I currently can think of two possible solutions:
>>>
>>> Move any code that ever interacts with Batik ( most of my
>>> application ) into the Batik UpdateManager thread, effectively
>>> making everything synchronous - kind of against the whole
>>> asynchronous-ness of Batik.
>>>
>>> The only other way I can think is to store the attributes all
>>> locally before the 'set' statement gets dispatched and make sure the
>>> 'get' statement will retrieve this value and not call
>>> 'getAttributeNS', but that seems like a rather silly option to me.
>>>
>>> By the way part of this started because I was merrily setting
>>> attributes and the getAttributeNS was returning 'null', and what was
>>> happening was the liveAttributeValue table had my latest and correct
>>> values in, while the 'attributes' table still had the original basic
>>> values in, and the only thing I can think of is that a thread
>>> somewhere is causing the listener between the two not to fire - any
>>> other suggestions?
>>>
>>>
>>> Any thoughts or comments grateful,
>>>
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail:
>>> batik-users-help@xmlgraphics.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by Tom McCallum <te...@googlemail.com>.
Thanks for your reply, interesting approach.
What you are saying is that instead of using the get/setAttribute routines
you call the fireDOMModification... functions instead? If my
understanding of batik is correct what you have effectively done is to
turn it into a synchronous update model.
(1) what is the performance like when you do this?
(2) Are there any problems you can tell us about to avoid?
(3) Are you saying that your way you cannot run any Rhino Javascript
functionality?
Thanks for your reply - most informative.
Tom
On Tue, 05 Feb 2008 15:51:01 -0000, Luca Piccarreta
<lu...@gmail.com> wrote:
> Hi Tom,
> I'm developing an SVG editor. And... I can't imagine many scenarios in
> which
> bidirectional interaction is so frequent with the SVG document.
> The best solution I found was an MVC approach, in which the document is
> a simple Apache DOM document, the view is a Batik Document, and the
> controller is a hierarchy of objects that forward DOM Mutation Events to
> the Batik Document.
> This way you can set and query attributes on the Apache Document without
> worrying about threads and queues and whatever.
> Mouse events are also dispatched through the controller hierarchy (they
> are
> captured and forwarded to the GUI main thread, SWT in my case).
> It cost me a couple of weeks of work, but now the code is so much
> cleaner.
> On the other hand this approach is not feasible if the Batik document
> runs
> any sort of scripts (the whole stuff works if the view is not... self
> modifying)
> Best of luck,
> Luca.
>
> Tom McCallum ha scritto:
>> Hi Everyone,
>>
>> Quick question of style really. I have created an app which has a
>> large amount of interaction between Java and Batik. I do all my
>> 'setAttributeNS' statements in the updatemanager thread, and
>> 'getAttributeNS' statements outside of this thread.
>>
>> Obviously this leads to some situations where the sub-thread with the
>> 'setAttributeNS' statement has not been completely executed at the time
>> of the 'getAttributeNS' statement in the java code.
>>
>> I currently can think of two possible solutions:
>>
>> Move any code that ever interacts with Batik ( most of my application )
>> into the Batik UpdateManager thread, effectively making everything
>> synchronous - kind of against the whole asynchronous-ness of Batik.
>>
>> The only other way I can think is to store the attributes all locally
>> before the 'set' statement gets dispatched and make sure the 'get'
>> statement will retrieve this value and not call 'getAttributeNS', but
>> that seems like a rather silly option to me.
>>
>> By the way part of this started because I was merrily setting
>> attributes and the getAttributeNS was returning 'null', and what was
>> happening was the liveAttributeValue table had my latest and correct
>> values in, while the 'attributes' table still had the original basic
>> values in, and the only thing I can think of is that a thread somewhere
>> is causing the listener between the two not to fire - any other
>> suggestions?
>>
>>
>> Any thoughts or comments grateful,
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
--
PS Note this is the new email address - delete term@blueyonder.co.uk as it
won't work soon!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by massimo citterio <ci...@sinapto.net>.
On Tue, 2008-02-05 at 16:51 +0100, Luca Piccarreta wrote:
> Hi Tom,
> I'm developing an SVG editor. And... I can't imagine many scenarios in which
> bidirectional interaction is so frequent with the SVG document.
such as smil animations?
> ....On the other hand this approach is not feasible if the Batik document runs
> any sort of scripts (the whole stuff works if the view is not... self
> modifying)
Maybe this is my problem! animations that modify svg runtime. What can
one do in such a case?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by Tonny Kohar <to...@gmail.com>.
Hi,
On Feb 5, 2008 10:51 PM, Luca Piccarreta <lu...@gmail.com> wrote:
> Hi Tom,
> I'm developing an SVG editor. And... I can't imagine many scenarios in which
> bidirectional interaction is so frequent with the SVG document.
> The best solution I found was an MVC approach, in which the document is
> a simple Apache DOM document, the view is a Batik Document, and the
> controller is a hierarchy of objects that forward DOM Mutation Events to
> the Batik Document.
Same here, We also developing SVG Editor and using similar pattern
like yours (MVC pattern).
In our case:
- Model -> SVGDocument wrapped in model class
- View -> our VectorCanvas
- Controller -> embedded in both the Model and VectorCanvas
Note: VectorCanvas is not descendant of JSVGCanvas or JSVGComponent.
Cheers
Tonny Kohar
--
Sketsa SVG Editor
imagine, design, create ...
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Asynchronous problem
Posted by Luca Piccarreta <lu...@gmail.com>.
Hi Tom,
I'm developing an SVG editor. And... I can't imagine many scenarios in which
bidirectional interaction is so frequent with the SVG document.
The best solution I found was an MVC approach, in which the document is
a simple Apache DOM document, the view is a Batik Document, and the
controller is a hierarchy of objects that forward DOM Mutation Events to
the Batik Document.
This way you can set and query attributes on the Apache Document without
worrying about threads and queues and whatever.
Mouse events are also dispatched through the controller hierarchy (they are
captured and forwarded to the GUI main thread, SWT in my case).
It cost me a couple of weeks of work, but now the code is so much cleaner.
On the other hand this approach is not feasible if the Batik document runs
any sort of scripts (the whole stuff works if the view is not... self
modifying)
Best of luck,
Luca.
Tom McCallum ha scritto:
> Hi Everyone,
>
> Quick question of style really. I have created an app which has a
> large amount of interaction between Java and Batik. I do all my
> 'setAttributeNS' statements in the updatemanager thread, and
> 'getAttributeNS' statements outside of this thread.
>
> Obviously this leads to some situations where the sub-thread with the
> 'setAttributeNS' statement has not been completely executed at the
> time of the 'getAttributeNS' statement in the java code.
>
> I currently can think of two possible solutions:
>
> Move any code that ever interacts with Batik ( most of my application
> ) into the Batik UpdateManager thread, effectively making everything
> synchronous - kind of against the whole asynchronous-ness of Batik.
>
> The only other way I can think is to store the attributes all locally
> before the 'set' statement gets dispatched and make sure the 'get'
> statement will retrieve this value and not call 'getAttributeNS', but
> that seems like a rather silly option to me.
>
> By the way part of this started because I was merrily setting
> attributes and the getAttributeNS was returning 'null', and what was
> happening was the liveAttributeValue table had my latest and correct
> values in, while the 'attributes' table still had the original basic
> values in, and the only thing I can think of is that a thread
> somewhere is causing the listener between the two not to fire - any
> other suggestions?
>
>
> Any thoughts or comments grateful,
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org