Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Ok so I understand what synchronized does and I know that it should be used when two methods access the same piece of data.
Now I have Hibernate DAO methods which update and read from a database. None of the methods share any data objects although they do access the same database (So one of the methods updates it and others read from it). Should I synchronize these methods? Or should synchronized only be used for data objects and not data in a database?
Its nice if you synchronize your methods so when you writing data to the DB and same time your read method execute then there is possibilities that you will get old data in output not the currently updated data.
Thanks
You should synchronize if concurrent executions of the method in different threads may cause problems. If your method in itself is thread-safe (i.e. no shared data) it depends on whether the resources you are using in the methods are thread-safe.
In case of a Hibernate database I think synchronization is not necessary. (just a guess, without seeing the code). Hibernate and the Database itself are pretty good in keeping their data consistent. (provided your DB and Hibernate setup is OK)
One more point to consider: synchronized code always carries the danger of deadlocks. This is especially true if you keep resources locked for a long time, like a DB-call.
So, in short: without knowing more of your application and setup: I would not synchronize this method. (YMMV)
You should use locking in this place, When the first method update the data then only other method should read it.
http://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html
Whether your program will fail or not depends on how your code is organized and what it is trying to do.
However, sharing the connection among threads is not a good practice, as you face issues with transaction management and its associate isolation.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live system
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
This question is more about design than a technical problem.
I'm developing a backend application using java and Spring Rest Services.
It is a small application so in the beginning I just created a controller for all the end points (5 or 6 end points). I have for example an endpoint to request a token i.e /token, and another to make a request, based on the token received previously i.e /readresource.
So now I'm wondering if I should split the controller into two or more controllers, each one with the end points that are related to each other.
Of course in terms of legibility of the code this is useful, but also, from a technical point of view, if the default scope of a spring bean is SINGLETON, if I have only one controller, that would make only a single instance for the whole application, so let's imagine we have two requests that arrive to the server at the same time, even if each request is running a completely separate thread, and they are requesting different end points, in the end they are accessing the same instance so, one request should wait for the other to finish, we cannot execute on the same instance two different threads at the same time, am I right?
So... in terms of performance or good practices, is it better to avoid big controllers with many end points to have instead many small controllers?
What do you think about it?
Thank you!
we cannot execute on the same instance two different threads at the same time, am I right?
Wrong. This is only the case if the method that is being called has the synchronized access modifier. Otherwise, concurrent calls can occur on the same instance in different threads.
Having multiple controllers has no obvious impact on the performance of the application. It means an extra bean is loaded into memory, which equates to a few extra KB of RAM taken up.
This cost is far outweighed by having code that can be read and understood easily. Remember, you shouldn't write code for yourself. You should write it for the next guy, or as a man much smarter than myself once said..
Write your code as if the next person to read it is an angry psychopath, and he knows where you live.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have query about usage of Collections.synchronizedMap(Map m) over Hashtable. We know that both will return a container where all methods are synchronized, so I don't see performance gain in any case.
Then why we have utility method(Collections.synchronizedMap) when Hashtable suffice the requirement.
Clarification with code will be helpful.
Hashtable and Collections.synchronized() exist mainly for historical reasons. Since Java 5, the new java.util.concurrent package should be used in most cases where you need multiple threads accessing the same collection.
Collections.synchronized() is still useful when you receive a Collection (eg. from third party code) which is not thread safe and you want to share it between multiple threads, without creating a new, thread safe / concurrent collection.
Note that in most cases, you should use java.util.concurrent instead. Synchronized collections will protect their internal state by synchronizing all access to the collection, but that is inefficient in term of performance and does not address the larger problem of the coherence of your data. For example, ConcurrentHashMap provides a putIfAbsent() method that will ensure the atomicity of that operation.
There are more implementations of Map than just HashMap, and you might want to synchronize access to any of them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is the general guideline/rule for filtering data? I am accustomed to seeing filters in an SQL statement in the WHERE clause, although there are occasions that filters introduce complexity to the SQL, making it massive and abit hard to read on first glance for intermediate developers, but well-written ones that look complex are well-tuned and optimal. Filtering can also be done in Java, but that of course has a drawback where unfiltered data from SQL can be huge and loading it in memory only to filter it out may be wasteful. Of course there are cases where you have no choice but to filter in Java if you have several datasources as dependencies that the filter requires.
Filter on the backend (sql), whenever possible. If that makes the query too complex for a junior developer then so be it. While clarity of code is important, you shouldn't make design decisions based on how well a junior developer will understand it -- its sufficient that he be able to use it.
This is particularly the case when talking about different layers, your junior developer might not know any SQL, would you then avoid a SQL backend entirely?
Write your SQL to be as clear as possible (without sacrificing performance), but do so with the expectation that the person maintaining it will be familiar with SQL and how it should be used. When crossing layers like this, a little "easier to understand" can really kill your performance (pulling data back from the db in order to update it, can take thousands of times longer than a update on the DB, inappropriate use of a cursor can be expoentally worse than a set based solution).
If the data is already in the DB, then it makes more sense to do the filtering within it, since the RDBMS will be optimized for this kind of work. If the filtering can be confusing to novice and intermediate developers, why not hide it in a view, and only grant access to the view, to the users in question?
I guess there are no definite answers to it. It depends of individual use case. Both filtering in java as well as SQL can be applicable depending on the application under consideration.
As you mentioned, filtering in SQL can make the queries complex and and costly. But at the same this can be improved using database tuning, putting appropriate indexes, table partitioning etc. This is specially the case where in the database design is still evolving and you can do these type of changes.
if you are working on a system whose database is already designed and you have hardly any scope for significant changes (and hence not much query/database optimization), in this case filtering in java is better option.
It all depends on specific use case.