http://activemq.apache.org/hello-world.html
In the above link author suggest to try transactional sessions, but unfortunately after lots of search on internet not able to get what transactional sessions mean.
And what are its pre-requisite??
The links that i read are:
http://activemq.apache.org/how-do-transactions-work.html
http://activemq.apache.org/should-i-use-transactions.html
Unfortunately still not able to get the meaning and particularly implementation of transactional session and why to use it.
Can any one provide sample reference implementation or tutorial for same. ?
Unfortunately still not able to get the meaning and particularly implementation of transactional session and why to use it.
Its simple if you want to perform an operation on a message , you received a message and did operation if the output is not correct , you dont want to proceed.
let me check for implementation will send if I find on my previous project
Related
Docs state obvious thing:
a method will throw an exception if it is executed inside existent transaction.
Can anyone give a meaningful example of when/why it can be used on purpose?
Well, there may be several use cases that require your code not to run in a transaction. You'd use NEVER to enforce that as opposed to NOT_SUPPORTED which would just "suspend" the current transaction and resume it afterwards.
One use case that we had would be sending an email after some transactional operation. Sending the email itself doesn't require a transaction and to make sure the operation was successful and didn't get rolled back at the last moment our email sending service uses NEVER (otherwise we might accidentally send a "success" email and then get a rollback). That way if someone would call it while the operation's transaction still hasn't been successfully committed yet we'd get an exception and know that this should be fixed.
One use case might be framework related code that handles transactions or scopes. Think of Apache Deltaspike, arquillian, hibernate, ...
If you expose public methods you might want to make sure they are not wrongly used inside some transaction. Instead of unintentionally messing up open transactions you would rather fail-fast using #NEVER.
If you want to modify a nontransactional resource inside your code and want to make sure that others know this fact, you can use this feature.
I'm trying to make an app that connects to Fitbit via OAuth2 using spring-social. I've had some troubles with this but I think I'm figuring things out. I notice that the OAuth process is initiated by making a POST to the ConnectController. Why is this done with a POST rather than a GET? I'd like to make it so that I can drop a link into a chatroom that the user can click to authorize my app to use their Fitbit information, which means that I'd like to start things off with a GET. Is there a reason why this isn't done? If I were to make changes to this effect (by subclassing ConnectController) would I run into technical/security problems?
There are 2 reasons:
The primary reason is that GET requests are expected to perform operations that are both safe and idempotent. But as a result of that request, you may (in the case of OAuth 1.0(a)) end up obtaining and possibly storing a request token as well as initializing the OAuth dance with the provider. This is not considered "safe" in the terms of a safe request. Moreover, it may or may not be idempotent, as repeating the request may result in a different behavior (depending the the provider's implementation of OAuth). While this may not apply to OAuth 2, it needed to be consistent between OAuth 1 and OAuth 2.
The /connect/{provider} path represents a single resource. There are only so many HTTP verbs to choose from without resorting to putting verbs into the path. The GET method for that path is already assigned to the request to fetch connection status for that provider (an operation which is both safe and idempotent).
Even so, I've encountered the use-case you're asking about. What I've done when I feel the need to have a link that kicks off the OAuth flow is to have a form that POSTs to /connect/{provider} and have some Javascript that submits the form for me, either as the result of a direct link (if the link is on a page in the app) or as the result of page load (if the link is to be given in an email or chatroom).
You're also certainly welcome to override ConnectController's behavior or even write your own implementation of the controller to meet your needs, even if they violate the reasoning behind why ConnectController is implementation the way it is.
The background: there is a requirement to attach auditing data to persisted entities, basically creation-timestamp + user ID and last-update-timestamp + user ID.
I'm not keen on passing the user ID as a method parameter through all layers/components. So I need to somehow pass user identifcation (derived from HTTP headers, the details are unimportant) through a REST endpoint (using RESTEasy, but that's probably not important, either) back to the data access/repository layer.
I've thought of using ThreadLocal but it feels a little hackish and might fail in a non-blocking IO environment. Maybe I'm wrong about that, not sure.
I also have a vague idea that AOP could help, though I'm not well-versed in AOP so not sure.
Any strategies appreciated, with or without code.
You can use entity lifecycle callback methods for your requirement: #PrePersist, #PostPersist, #PreUpdate, #PostUpdate.
It is one of the auditing strategies mentioned here.
It turns out that Spring's SecurityContextHolder is a reasonable place to do this (don't ask why the application isn't already integrating "properly" with Spring Security). It's basically the ThreadLocal option but with some nice interface around it.
The tradeoff is that you need to be acutely aware of the thread-bound nature of this solution. A controller that somehow uses other thread to do the work that needs the user context, will need to take some steps to make sure those threads can get it since they don't, by default, inherit the ThreadLocal. There is a mode you can set on SecurityContextHolder that will use inheritance of the ThreadLocal in any newly created threads, but that does not help if a thread pool is used (since threads won't be created by the request thread but rather pulled from the pool). Even then, most thread pools provide a way for the client thread to do "something" when obtaining and releasing threads, so it's possible to pass the security context on that way.
I followed the following tutorial of Netbeans on creating the Enterprise Application using the IDE. I just wanted to know why the usage of Message driven bean is preferred here for the save or persist method? And why not for the other database operations such as findAll?
https://netbeans.org/kb/docs/javaee/maven-entapp.html
Message Driven Beans are asynchronous components, to illustrate the concept, asynchronous communication works pretty much like email communication, you send the email and that's it, you can only hope for the best, and expect that the recipient processes your mail as soon as possible and reply back if necessary (in a different communication), on the other hand, synchronous communication works pretty much like a phone call, you get your response during the same communication, without the need to start a new one.
In your case, when a client invokes findAll he's quite likely expecting to get a list of results in the same communication (synchronously: 'server, give me right now all the customers in the system'), in which case an MDB (asynchronous) is simply useless, on the other hand, when a client invokes save he might not want to wait for an answer (asynchronously: 'server, just try to save this info, i don't need to know right now if you succeeded or not').
There's a lot more info here.
We want to write operation logs in our application for all the operation being made to DataBase. The operation log should contain the operation info(the data being "add/modify/delete") and the result of the operation(success/failure).
Since there are more number of action classees, adding the code to write operation log in each action class looks difficult. So I thought of writing this part of code in the Servlet Filter.
But I have a problem here, I need to know the operation status(success/failure) but this is not possible in the filter with out parsing the response object. But parsing the response object looks difficult.
Can you suggest any alternative way to do this?
Thanks,
Chandra
If your application is AOP-based like Spring, then you can define aspects which can check for criteria like classes of a particular package, methods of a particular type (get/set/both). Using these aspects you can add logging.
I think the best way to achieve this is to add some extra logging to the JDBC driver. In the past I used Log4JDBC project.