Author |
Message
|
CHF |
Posted: Mon Aug 15, 2005 9:18 am Post subject: WBIMB6 Persistent environment? |
|
|
 Master
Joined: 16 Dec 2003 Posts: 297
|
Does any one know whether persistance is there in MB6.0 to maintain state accross msgs or msgflows?
Thanks. _________________ CHF  |
|
Back to top |
|
 |
vikgathy |
Posted: Mon Aug 15, 2005 9:36 am Post subject: |
|
|
Newbie
Joined: 15 Aug 2005 Posts: 1
|
I heard there is going to be a Persistent Environment in 6, holding state between messages like caching a DB table for routing messages instead of SQL Query for every message to find route destination.
I think we got to wait till september till we find more on it.If there is someone in this forum who is working on beta they can definetely answer. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Aug 15, 2005 9:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If there is someone on this forum who can definitely answer, it's extremely likely that they aren't allowed to answer.
So why ask? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mlafleur |
Posted: Mon Dec 05, 2005 11:33 am Post subject: |
|
|
Acolyte
Joined: 19 Feb 2004 Posts: 73
|
Now that version 6 is out, does anyone have an answer to the original question? |
|
Back to top |
|
 |
TonyD |
Posted: Mon Dec 05, 2005 11:41 am Post subject: |
|
|
Knight
Joined: 15 May 2001 Posts: 540 Location: New Zealand
|
Quote: |
It is sometimes desirable to store data for longer than the lifetime of a single message passing through a flow. One way to do this, is to store the data in a database. This is good for long-term persistence and transactionality, but access (particularly write access) is slow.
Alternatively, you can use appropriate "long-lived" ESQL data types to cache data for a certain period of time. This makes access much faster than it would be from a database, though this is at the expense of shorter persistence and no transactionality.
Long-lifetime variables are created by using the SHARED keyword on the DECLARE statement.
Long-lived data types have an extended lifetime beyond that of a single message passing through a node. They are shared between threads and exist for the life of a message flow (strictly speaking the time between configuration changes to a message flow).
|
|
|
Back to top |
|
 |
wschutz |
Posted: Mon Dec 05, 2005 11:45 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Yes, there are SHARED variables that you can set in one thread of a message flow and access from other threads (it must be in the same EG). You can use them to do things like load reference tables or pass counters around. They live for the lifetime of the flow (ie, until redeploy or restart).
DECLARE mySharedvar SHARED ROW ..... _________________ -wayne |
|
Back to top |
|
 |
JLRowe |
Posted: Mon Dec 05, 2005 3:51 pm Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
How is synchronisation between threads handled?
Can you lock a shared variable while you update it? |
|
Back to top |
|
 |
wschutz |
Posted: Mon Dec 05, 2005 4:53 pm Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Quote: |
If ATOMIC is specified, only one instance of a message flow (that is, one thread) is allowed to execute the statements of a specific BEGIN ATOMIC... END statement (identified by its schema and label), at any one time. If no label is present, the behavior is as if a zero length label had been specified.
The BEGIN ATOMIC construct is useful when a number of changes need to be made to a shared variable and it is important to prevent other instances seeing the intermediate states of the data. Consider the following code example:
Code: |
CREATE PROCEDURE WtiteSharedVariable1(IN NewValue CHARACTER)
SharedVariableMutex1 : BEGIN ATOMIC
-- Set new value into shared variable
END;
CREATE FUNCTION ReadSharedVariable1() RETURNS CHARACTER
SharedVariableMutex1 : BEGIN ATOMIC
DECLARE Value CHARACTER;
-- Get value from shared variable
RETURN Value;
END;
|
[/code] |
_________________ -wayne |
|
Back to top |
|
 |
JLRowe |
Posted: Tue Dec 06, 2005 4:27 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
wow, impressive stuff...
watch out Java and C#, I for one, welcome our new ESQL overlords |
|
Back to top |
|
 |
|