Is the RsaSHA256Signer thread safe and reusable or is it intended to be one-time use only?
Yes RsaSHA256Signer is thread safe and reusable. It uses java.security.Signature to create the signature.
http://docs.oracle.com/javase/7/docs/api/java/security/Signature.html
Related
In Broadleaf, both SessionOrderLockManager and DatabaseOrderLockManager can be used by CartStateFilter to serialize user requests.
It appears that the former locks on the session associated with the request, and the latter locks on the order embedded in the request body.
My question is that, why both implementations exist? Are there differences in the provided semantics? Are there scenarios where session-based locks won't suffice? (I found through git history that the database lock implementation is introduced after.)
Many thanks!
p.s. I'm not familiar with HTTP sessions. Please correct me if any statement is wrong.
[Edit] Here's another related question: why use locks at all? It seems that marking the service methods #Transactional suffices.
Got an app where a gift card can be used. A gift card key is requested. What is the best way to handle frequently bad key attempts? Currently we register ip-Addresses of frequently failed requests and ignore further trials after a
Thread.Sleep(progressiveDelayTime);
This will 'waste' a thread, so guess not the best solution.
Thanks for any help.
The easiest improvement would be to use Task with await. This won't waste a thread at lest
await Task.Delay(progressiveDelayTime)
In Play Framework, if your code runs within Future, it jumps from one thread to another. I have a config object which is instantiated per request, and need to be stored in the Threadlocal. However when the Future is involved, Threadlocal values aren't consistent anymore. How do we try to make the Threadlocal consistent throughout the life of request even if it is jumping between different threads?
Thanks
You can use HttpExecutionContext. Please refer https://www.playframework.com/documentation/2.5.x/ThreadPools#java-thread-locals.
I'm using the BOX SDK to access box.com items programatically. SDK gives me the new pair of tokens whenever current access token is expired for a single thread request.
My question is how to 'refresh' the access token in multithreaded application (website). Making the OAuthDataController.doRefresh to synchronized will solve my problem? Or do i need to put some additional logic.
P.s I've helper class to load and archive the tokens in/from txt file.
Please let me know. Thanks.
If you are writing a multi-threaded app, then you need to synchronize on the refresh block.
In java, the classic way to do this is by using a singleton. Other languages allow similar mechanisms to coordinate an operation that needs to be coordinated across multiple threads.
I wonder what's the best practice to make a db update thread safe.
I am calling a stateless session bean's
public void addReservation(Reservation reservation)
Before adding this reservation - I would like to check if there are still valid places for that reservation, using an entity bean's method
public boolean isThereRoomForAnotherReseravtion()
I read here that synchronized method will not solve the problem.
I thought of using stored procedure with a validation rule for the solution, but it doesn't sound right.
Is there a standard practice for making write procedure thread safe?
Regards,
Danny
No Java synchronization can actually help you since there can always be some second database client (maybe even your own application in clustered environment) that can access the database simultaneously.
You need to go deeper on the database layer and use database locking facilities like optimistic/pessimistic locking. JPA 1.0 supports the former, 2.0 supports both. The choice depends on how much concurrency you suspect to experience.