anything like 'session variable' in XData?

BIZ TMS XData
1

I'm setting up a proxy service that gets a request and fulfills it by requesting data from another service, extracting a subset of the returned data, then returns it to the client. It's transient data, so no DB is needed. (I will likely have a way of managing authorized users. But this data doesn't need to be saved.)

I want to be able to set what amounts to 'session variables' -- the client sends some data once, then makes one or more requests that use that data. If it needs to change, it can just update it.

For example, the remote API needs its own API key. Instead of adding that to every request, I'd like to send it with some other data that is used for a bunch of following requests.

The alternative is to send one gigantic request and get back a collection of reply data.

But there doesn't seem to be any notion of a 'session' with XData that I can find.

What if I put a TList<...> or TDictionary<...> in the service implementation?

The problem is, I don't know what the lifetime of this thing is. So if I send a Put request to set a variable defined in the service, then send a Get request to read it, does it persist?

I know there's automatic object management, but it's not clear to me if that's the same thing.

As an example, I'm working with the Swagger demo that's got some math functions in it. Suppose you wanted to define a simple filter function that takes a 3x3 convolution matrix. You might want to pre-define several of them to use, named M1..M6 say. Then you apply one of these to any number of data samples. So you have an array or Dictionary of these that you define first. Then you send a series of requests that specify which one of these pre-defined matrices, M1..M6, to use as the filter. (In my case, the pre-defined data can be rather large, and I'd prefer not to have to send it with each request since it rarely changes for a given batch of requests.)

2

For testing purposes, I declared a local variable in the implementation section and ... it appears to persist between service calls.

Since I believe everything is running in separate threads here, this needs some kind of critical section synchronization to ensure no conflicts, right? What's recommended for that inside of XData services?

3

By doing that you are adding state to your server. Be aware that this might cause problems for you, by limiting your server. If you restart your server, state is gone. You can't scale your server, i.e., having multiple copies of it, since each copy will have it's own state. You can't run in on Apache, for example, because Apache does scale it automatically, creating multiple copies of the modules. And so on.

The "solution" to that is to always persist the data - either in database or any other sort of storage.

Having said that, yes, "all" you have to do is to declare some global variables that will hold the data, since the service implementation object is created and destroyed upon each client request. And yes, it's up to you to protect that global data from being accessed by multiple threads. Critical section, monitor, slim multi-read-single-write locks, whatever fits best your implementation.

4

I understand. I'll typically have between 10 and 100 requests all submitted in a batch that will be processed at once, and they all require a big chunk of the same preamble data. Since the actions on the XData server are automatically multi-threaded, it means they'll all be executed in parallel, which is what I'm wanting. The other API is set up to allow that. They should each take 5-10 seconds to run, but I've seen them take 30 seconds, I guess due to the load of the other service I'm calling. That time isn't of any practical consequence. (every once in a while one will time-out and need to be resubmitted.)

The preamble data is only needed for as long as it takes to send out all of the requests. At that point it'll be deleted, or it can just get flushed if it's more than a couple of minutes old. I could send a separate request to do the cleanup.

The alternative is to submit them all as one big request with all of the required data in one message, but then I'd have to split them up into separate threads before calling the other service.

But on the client side, I'd like it to know when each individual query is complete, not treat them like one huge batch. Is that possible? That is, can I get multiple responses returned asynchronously for the same request?

From a use-case standpoint, in this particular instance I've got a bunch of similar requests all being sent in parallel to the same remote service, sort of like asking for a bunch of different stock quotes (my application isn't that simple, but they're analogous). Another approach is to send the same basic request to a bunch of different services, eg., if I were setting up a financial app that goes out and requests account balances from a bunch of different banks. (I understand there's a common API that independent financial institutions are beginning to implement that makes something like this feasible.)

I guess this is more of a middle-ware function that could have its own specific solution in XData. The data only needs to persist as long as the batch itself is being processed, which could be managed by a single task. If it fails, the whole thing can just be resubmitted, or just the parts that failed to complete could be resubmitted. Once it completes (both success or failure), the data is no longer needed. Whatever the client got can be used, and what's missing can be requested again. Adding a DB seems like a lot of overhead to add for what amounts to some transient variables. That's what session variables are used for in most web sites, right?

5

Session variables are not supposed to hold big amount of data. You probably need to add another layer to this and don't treat this as a single request, but as a job. Create a job, update job, check if job is completed, check if step of the job is completed. There is no generic solution, what you need is a little bit specific. I didn't say you should use a database, but a storage. It could be database, a key/value storage like Redis, SQLite, some file, etc.. Or memory, if the issues I mentioned are not a problem for you (scalability, load balancing, etc.).

6

I think for now I'll build it to send all of the data in each request, then have a flag that lets me say if some has been saved previously and how to find it.

1 Like