my question is about thread's,
I am studying ejb and I see that it has many thread access controls, and working with ejb I could realize or at least imagine that all the access from the "remote client" (my doubt is this, only ejb?) Is thread based?
Or in the ejb control the accesses of the thread's, my doubt is can I say that all the access coming from the remote client are thread's or can I manipulate those accesses with the use of api Thread?
I do not know if I was very specific, if so, is this also true for JSP'S and Servlet? Or just in case the EJB's can see I'm a bit confused.
Thank you
One of the basic goals of EJBs, since the beginning, is to relieve programmers from the pains and dangers to deal with thread management. Thread management is the responsibility of the Containers and it's not allowed to developers to deal with them.
As you can see from the link below "creation and management of threads" it's not allowed:
EJB Restrictions
Related
Another programmer told me about a problem, that one user sometimes sees the data of another logged-in user. Probably they are requesting the same context at the same time. I thought, that is impossible to happen? Since Garbage Collection, Container-managed Transactions and JSessionID
Without looking at the code, it is hard to guess. But maybe you have hint.
He is using this structure:
JavaEE 6 coded Web Application, using EJB and Web Container seperatly on a Glassfish v3
JSF + PrimeFaces Framework
Thanks in advance
The good news is that the EJB architecture is absolutely capable of isolating data, so this will be a bug in your code.
One thing to look for is the kind of beans you're using:
If you have stateful beans, the container will make sure each client gets the right instance.
If you use stateless beans, these are shared between clients. If you're storing any client-specific state in these, this could easily get shared across sessions.
If you use singletons, you need to make sure that no session-specific state is stored, and that any shared state uses appropriate locks.
It's also worth checking your application logic - if it appears data is being shared across sessions, is it possible it's just the wrong data?
Finally, the big thing you're going to need is appropriate debug logging. You'll need to get enough information about what's going on from the log to identify where the problem is going wrong. Unfortunately these kind of contention issues can be fiddly and hard to catch, especially with a debugger, but appropriate logging will make your life much better in any case.
Of course, this is all quite vague and generic, but without more detail on the system that's inevitable. I would suggest looking for state stored on stateless beans as a first step though!
I'm trying to decide how to secure a modern web application. I am relatively new to the Java EE 6 technology stack, but I've done some pet projects that didn't utilize security, so I'm looking for some general guidance on what's even possible using out of the box Java EE 6 security.
I understand that declarative security allows you to protect resources based on what role(s) have been assigned to a user attempting to access that resource. So, for example, a user requests a page at a particular URL, the Java EE server checks the user's credentials to see if they're authorized to access that page. This makes perfect sense for resources that only to be accessed by authenticated users. Good examples include administration pages, user account setting pages, restricted content areas.
So as long as I divide a website into secure and unsecured areas, that works fine and I have no questions. But how do I deal with the situation where I have a resource that I want to behave differently based on the authentication level of the user for declarative security.
For example, I may have a home page on a website that displays one view with a login prompt if the user is an unauthenticated user, but if an authenticated user visits that same resource should display some sort of control panel with account management links, etc instead of the login prompt.
How is this achieved in modern Java EE 6 applications? Declarative security doesn't seem expressive enough to allow this to happen as it's very "all or nothing". I've read a little about programmatic security, but all the guides talk about servlets and in a modern web application I would assume that JSFs would be the way to go, not raw servlets. I want to ensure that when I secure a web application with this mixed content that depends on the authentication status of the user that I don't end up spamming security code all throughout the web app because that's extremely error prone, and very messy.
Given the above requirements what solutions would you recommend? I'm not looking for a step by step, just some helpful pointers to get me started in the right direction. Both "Here's what you can use" and "here's how it's going to fulfill your goals" would be helpful!
One last thing, I'd like to avoid loading the Spring suite onto this webapp. I like using the Java EE 6 container technologies as much as possible, and I've heard there are issues making Spring managed beans and Java EE container managed beans available to each others' contexts.
Well, you should read: the Security chapter of the Java ee tutorial.
In a nutshell, either in servlets or EJBs you should:
Declare the security roles involved: #DeclareRoles("javaee6user")
In your servlets either
use #ServletSecurity(#HttpConstraint(rolesAllowed = {"javaee6user"})) for the whole servlet (declarative security)
in the servlet's methods check with request.isUserInRole("javaee6user") just as you did in 'old' servlets (programmatic security)
In your EJBs either
declare the role(s) allowed for a whole method with #RolesAllowed("javaee6user") (declarative security)
inject with #Resource SessionContext ctx; the bean context, and invoke ctx.isCallerInRole("javaee6user") inside your method, just as you did in 'old' EJBs (programmatic security)
I have a question about threading in Silverlight. I come mainly from a winForms background and usually use the following wrapper class to do my threading:
http://msdn.microsoft.com/en-us/magazine/cc163644.aspx
It has worked for doing window development but I am not able to use it in Silverlight. The reason is because ExecutionContext is marked with the [SecurityCritical] attribute making it impossible to call from Silverlight.
Is there a similar wrapper class out there for Silverlight or is there a way I can get around this issue?
Thanks!
I would not use the class you cited even in a WinForm application. It still uses Thread.Abort which can (and probably would) corrupt the app domain. Instead, use the new Cancellation mechanisms in the Task Parallel Library. You will have to rethink your whole approach to cancelling the work items though. This is because you can no longer rely on forced termination and have to use cooperative termination instead. The advantage is that the later can be guaranteed to avoid corrupting the app domain.
Take a look at cancellation tokens (via the CancellationTokenSource) available only in SL5. It uses a similar mechanism as the one used in your MSDN mag ref.
This is a good 'how-to' article. Some MSDN References here, as well as a lengthy but great article here
All the best, and welcome to XAML programming :) You won't look back!
Rewrite existed code for using a "Task" (Task Link) or a BackgroundWorker (BackgroundWorker Link).
We should use a newest technologies, which give us a technological evolution.
I'm working on a JSF 1.2 project which has AJAX functionality on it's pages (using RichFaces).
My bean builds a list of objects to be edited and then has methods to support the editing and the bean is session-scoped. I will be using a a4j:queue so that only one AJAX call can happen at a time.
I'm curious if it is wise to use synchronization (locks on objects, or perhaps collections from java.util.concurrent) in the managed bean. Is the extra work needed to implement synchronization/thread safety really needed? The site I am working on has many users and needs to be reliable but it has a LOT of managed beans, and I'm curious how concerned I should be about the thread safety of managed beans overall.
Do you take extra steps in backing beans for thread-safety?
Thanks in advance.
a4j:queue won't prevent the user from reloading the page / clicking another link while the AJAX call is in progress.
Yes, we can probably trust the user not to click many different links right after each other, but what about requests not triggered by the user, for instance by a4j:poll?
Note that replacing all collections with their thread-safe equivalent might not be enough to make your application thread safe.
That said, depending on the degree of reliability your application needs to meet, this problem might or might not deserve your attention.
You need to keep scope in mind.
Request scope - thread safe, session scope - not thread safe
If you need to be able to open multiple browser windows or tabs, then you can use something like a Seam conversation to protect from editing the same object from two windows/tabs.
If it is SessionScoped you must take care to use some thread-safety mechanisms. If it is RequestScoped or ViewScope'd, then it is safe to share class variables between methods.
I am designing a remote threading primitive protocol. Currently we only needs mutexes (i.e. Monitors) and semaphores. The main idea is that there doesn't need to be a central authority - the primitives should be orchestrated amongst the peers that are interested in them.
I have bashed a few ideas around on paper and in my head for a few weeks; but I think I should really have a look at prior literature. Is there any?
It will run over XMPP - but that is an implementation detail. I am just looking for a specification or such on the actual protocol flow - so it doesn't really matter what protocol the literature originates from.
Thanks a million.
Distributed mutexes are tricky structures. You need to handle all sort of weird conditions that do not exist with a single machine based implementation. In particular you need to handle situations where agents lose comms with the group and still hold a lock on a shared resource. Additional to that scenario there are complex scenarios where your group is fractured and you grab a lock on a resource. When the fractured groups join into a big group you need some way to reconcile the locks which is far from trivial.
I would strongly recommend looking into some messaging based middleware such as Erlang and JBoss
I would also recommend posting separate questions on the particular distributed algorithms / data structures you need implemented. It's possible that you could get away with an out-of-the-box implementation in a middleware library that could be adjusted to meet your needs.