I am very new to concurrency, so please forgive me for being naive. I have a thread that runs some shell scripts and I wanted the user to still have a responsive UI while the processing is happening in the background. But in the processing I need access to the session object.
Why would you need that? You can pass all information at the beginning of the thread. And don't pass EOs, pass global ids. Never share EOs, editingContexts, or sessions around! Never pass mutable objects without copying them for thread usage. Don't use static variables in utilities. Work with instances or make your code either synchronized or re-entrant.
This is a quite painful subject and it can bite you pretty badly if you get it wrong (which you most certainly will, as everybody who started out on that). So keep it as simple as possible and follow the basic rules:
- no EO crosses thread boundaries
- no session access outside request-response loop (meaning, from multiple threads)
- pass in information, don't reach out for it
- work on copies of the data or immutable objects (remember a container might be immutable but the objects inside might not be)
Any help on this would be greatly appreciated.
Really, you don't want to get into that! Pass to the thread all information it needs to know and use the thread hooks for state information. Use concurrent request handling to keep the UI response if you want, but if you're forking a thread, that isn't even absolutely necessary (though recommended).
cug
--
http://www.event-s.net
_______________________________________________