Chin,

Scratch data exists for voice elements only because only voice elements need a place to store information from page to page. Since actions and decisions execute immediately, there is no need for scratch data. Even if it were introduced, it would be deleted once the action or decision element ended.

Is the purpose to store information somewhere in memory that stays alive for the duration of the call? If so, that is what Session Data is designed for.

If the purpose is to retain the data across calls, and possibly across applications, then there are various solutions.

1) Use a file or database. This is not very desireable due to the overhead involved.

2) Use static variables in classes. We recommend against this because of the cosequences: if you run the update script the static variables are reset, any call to the application can change its value, and most importantly, that value is not replicated using Resin session replication so would be lost if a failover event occurred. If this is desireable behavior, it will work.

3) Use a singelton class. This has very much the same limitations as option 2, though you can build into it the ability to resolve some of those issues (like potentially preventing all but a certain call from changing its data). There would still be a problem in the case of a failover event.

4) Separate the data on a separate thread, servlet, or machine and use RMI to get the information back and forth. While this is slower than direct memory access, it should be faster than accessing a database. A brief aside: we had an internal application building contest within the company a while back and one team built a submarine game in which callers simultaneously called into the system could shoot at eachother. Their game engine existed as a separate process that the voice application accessed via RMI. That was how they were able to have data created by one caller get shared with other callers and persist even if certain callers hung up.

Hope this helps!