B4J Question jServer persistance

[Dave G]

Adapted the ServerHelloWorld example to act RESTFUL. I thought I saw somewhere that the sessions were state-full i.e. remained there for the session for a specific IP client, I observe that the Initialize sub is invoked every time a request is received and the Class_Global are initialized. Is this correct?

Thanks

 

[Dave G]

I believe I found my answer in https://www.b4x.com/android/forum/threads/server-building-web-servers-with-b4j.37172/#content

Each request is handled by a new instance of the handler class. A handler class should have an empty Initialize and a Handle sub with the following signature:

and

A multithreaded handler means that your handler code will be run by a thread from the server threads pool. Multiple instances of the same handler and other handlers can be executed in the same time. As long as you don't access any global variable out of the current handler instance you should be safe.

A single threaded handler will always be executed by the main thread. This means that if there are multiple requests they will be queued and executed one by one. Single threaded handlers can be useful in many cases.

So if I want to persist data I have to do it outside of the handler instance.

 

[Erel]

So if I want to persist data I have to do it outside of the handler instance.

I don't think so. Use sessions: https://www.b4x.com/android/forum/t...ads-sessions-and-server-events.39969/#content
If you need more persistence then it is best to use ConnectionPool with a database.

 

[Dave G]

Thanks. I've developed several Unix/.NET socket based servers. I would instantiate a new instance for each mobile unit. That instance had significant 'context' including .NET DataTables (200+ fields). The instances persisted through all of the requests. In addition, I'd break up large results and send around 2K at a time. So, I would continue to read the DataTable for each subsequent request until all data was sent. The server was single threaded and used a third party socket component from IPworks, which was mutli-treaded and queued requests. In over 20 years never had a mobile unit 'hang' due to long transactions. Not having to go to the database to retrieve context provided really great performance. The application was installed in retail stores and generally had 3-8 users, so being single-threaded didn't hurt performance.

The B4J HTTP server is my attempt to replicate the same environment as I had with .NET. I've already implemented a B4J socket-based prototype that is single threaded and persists instances of the server app. Had hoped to do the same with RESTFUL HTTP, but doesn't seem to be possible to easily replicate. BTW, I did implement an IIS RESTFUL/Sql Serverr warehouse application that was very successful. It served over 50 mobile units with the Xamarin/.Net clients using Async/Await (resumable subs) to prevent the UI from not responding during long transactions. This application persisted context (small amount of data) on the mobile unit and sent it to the server, so it was well suited to IIS RESTFUL web services.

BTW, my first mobile database server was developed (early 90's) on Unix that accessed Oracle using Telxon mobile units. The mobile requests/responses were limited to 1K and were served using a 9600 baud serial connection! Each mobile unit had a separate Unix process that persisted context. With the architecture I developed I was able to replace the mobile units (Telxon to Symbol VB.NET) without changing anything on the server. Then I was able to replace the server (Unix to Windows .NET) without changing any of the mobile code. Then I replaced the Windows Mobile VB.Net with Android Xamarin without changing the server. Could actually run the Windows Mobile devices along side the Android devices. Rewrote 14,000 lines of VB.NET to Android Xamarin. Unfortunately those clients went belly up during Covid and won't be back. That's my story.

 

[Erel]

Had hoped to do the same with RESTFUL HTTP, but doesn't seem to be possible to easily replicate

Why? It is very simple to use sessions.

 

[Dave G]

Because to got the impression from a response that if I need to persist a lot of data (which I do) that I need to retrieve from a database using the connection pool. I will revisit this when I have some more time. Thanks.

 

[Erel]

It is not about the data size. The question is whether it needs to persist after the server is restarted.

 

[Dave G]

Thanks for the clarification. I'll look into it further soon.