On Wed, Jun 17, 2009 at 10:38 AM, ws_dev2001ws_dev2...@yahoo.com wrote:
Hi all,
is it possible to persist the state of an scxml instance into a database ?
snip/
Its almost always possible (at worst as a blob) but feasibility is
really an application-specific concern. In very few cases, it may be
possible to store just the ID of the current state. More often,
multiple other pieces of information need persisting. Some details on
that are in this thread:
http://markmail.org/thread/7rzalbdmbtvhr4kq
What would be the api call structure to achieve this?
snap/
When not using java.io serialization, its upto the application to
persist what it needs. The idea of creating a Memento design pattern
based SCXMLExecutorState interface in the Commons SCXML library has
been entertained with the idea that implementations of the interface
would plug in the appropriate persistence mechanism based on
application, but at the time there seemed limited value to defining
such an interface in the library itself.
I understand that the
junits have roundtrip testcase to check for serialization and
deserialization. However, file system based operations are not currently
envisaged. I am looking at the 0.9 release of commons-scxml. Further, I have
a custom eventing framework and would like to use this within the scxml
state machine so that all calls to fireEvent are going to create and emit a
custom event which would cause a transition to be taken for a statechart
instance.
The initial requirement of persisting the state to a database is given a
failure scenario when post restart the statechart instance needs to be in a
particular wait state and awaiting action(input event fired to it) so that
the next state(if not a 'final' state) can be transitioned to.
snip/
The primary usecase for Java serializability had to do with session
use in servlet and portlet environments, which seemed a common pattern
for some Commons SCXML users -- whereby session persistence and
failover for clustered app servers came into play.
-Rahul
Regards,
R2D2.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
