8

I am working with Hibernet and Spring it's going good..but I have some doubts

1) why spring scope is singleton by default?Is there any reason for that

2) Can I write final varible in Hibernate entity? Example : 

@Entity
public class Emp {
  @Id
  private Long id;
  final private String panNo;
}

Can I write like above

3) static varibles can Searlizable?

Jakub Kubrynski
  • 13,724
  • 6
  • 60
  • 85
user2963481
  • 2,003
  • 6
  • 19
  • 20

2 Answers2

26

If you look at Spring closely enough, you'll see that Spring helps you write services, NOT data objects. With Spring, you still have to manage your own domain objects, may it be relational data objects or straight POJOs, and pass them to a Spring managed service, repository, and controller etc as input.

So, with that in mind, it should be clear why Spring's default scope is NOT prototype, session, or request: we don't need to create a new service every time a request comes in. But why singleton? When a service is stateless, it's thread-safe, and it can scale to any number of concurrent requests, so there's no need for a second copy of the same service.

Unlike EJB, where there's stateful and stateless beans, Spring has only one type of bean: stateless. If you want to manage state, you'll have to do it yourself. And like previous answer has already pointed out, stateless is by far the better choice because it's faster, more scaleable and easier to maintain, it's also what REST architecture promotes. Stateful beans may appear great on paper, it has been proven over the years as quite a disaster.

Christopher Yang
  • 3,769
  • 4
  • 30
  • 27
  • 1
    Doesn't the Spring bean being a Singleton get in the way of writing multi-threaded programs? That was my thinking and why I used prototype-scoped beans. – pyetti Jan 29 '16 at 00:43
  • 3
    A singleton doesn't necessary breaks down in a multi-threaded program, the deciding factor is statefulness vs. statelessness. Any class without instance variables is always thread-safe. A singleton with only thread-safe singletons as instance variables (see @Autowired and @Inject) is also thread safe, you can write a program to test it. – Christopher Yang Jan 29 '16 at 17:17
  • 1
    I don't doubt that it's thread-safe. My question is about separate threads needing access to the same bean, which I imagine will slow down processing, as there is essentially a lock on that bean. No? – pyetti Jan 31 '16 at 21:23
  • 2
    I'm guessing when you say "separate threads access the same bean", you're talking about accessing the same instance variables in a single bean? Unlike local variables in a method, Instance variables live on the heap and they do not get garbage collected after a method invocation. Getting access to these variables can be contentious and reduce liveness of a program. By having only thread-safe singletons and ThreadLocals as instance variables, you basically avoid contentions (a.k.a locks) and mandate that states must be maintain elsewhere, e.g. client side, distributed cache or database. – Christopher Yang Feb 01 '16 at 17:49
  • What about "one bean per bean id in a container" idea? Why does Spring create different objects for different IDs if services are stateless anyway? – Bishwas Mishra Nov 25 '20 at 00:00
11

Stateless beans rules :) If you're not going to hold state data in beans then it's enough to have only one instance of each bean. You should also remember that it's not JVM singletons - just Spring singletons. So you don't have to provide only private constructor and any getInstance() methods.

Quote from Spring documentation:

When a bean is a singleton, only one shared instance of the bean will be managed and all requests for beans with an id or ids matching that bean definition will result in that one specific bean instance being returned.

Only when you have to keep some session details you should use for example session scope.

Jakub Kubrynski
  • 13,724
  • 6
  • 60
  • 85