Unfortunately right now I don't have enough time for a proper performance analysis.
It seems this group is quite dead, are there any other groups (besides Stackoverflow) where people talk about Guice? Thanks for the heads up about guice-persist, will look into it! Am Montag, 1. Dezember 2014 23:20:04 UTC+1 schrieb scl: > > Concerning the cost of singelton vs. default scopeI cannot give you an > answer. Maybe you just go ahead and write some performance test for it and > run 20 or so threads in a loop and inject the same class 100 times... > > But for the transaction: I always have them on the service layer. Now this > is not a very precise answer sinc often a service will not opnly call DAOs > but also other services. But the transactions have a semantic in that they > guarantee atomic execution of a sequence of SQL statements. Which > statements have to be grouped into a logical set is a business requirement > and most often this will involve more than one entity. > So the more detailed answer is: > As close as possible to the DAOs but as far away as it needs to be in > order to span all entities involved in the operation. > > By the way: guice-persist is currently not maintained. You may want to > have a look at the onami-persist guice extension. > > Am 1. Dezember 2014 18:24:11 MEZ, schrieb [email protected] <javascript:>: >> >> There has been a similar thread here already ( >> https://groups.google.com/forum/#!searchin/google-guice/Should$20Guice-Injected$20DAO$27s$20be$20Singletons$3F/google-guice/3B8XrwB-p18/B6OF13HWRnEJ) >> >> but I don't think it has received a satisfying answer yet. >> >> The baseline: >> We are using Guice in a JSF/Primefaces webapplication running on Tomcat. >> Persistence is handled via JPA/Hibernate. >> >> Right now ALL our DAOs (approx. one per Entity) are annotated as >> @Singleton. The only reason for this seem to be performance concerns as >> another (non JSF but Webservice) part of the application will receive >> thousands of hits per seconds and our main developer believes, that >> constructing a DAO Singleton once and then getting it in a synchronized way >> is cheaper than to always inject a new instance (which is the Guice Default >> Scope). >> This goes contrary to what the Google Guice Wiki writes about Scopes: If >> the object is *stateless* and *inexpensive to create*, scoping is >> unnecessary. Leave the binding unscoped and Guice will create new instances >> as they're required...Although singletons save object creation (and later >> garbage collection), initialization of the singleton requires >> synchronization; ... >> >> Now, what exactly does "initialization of the singleton" mean in this >> context? Is initialization done once? Everytime it is injected? >> >> Is the assumption correct that, with the above scenario (thousands of >> hits per second) using @Singleton annotated DAOs is faster and better >> resource wise than using Default Scope? >> >> As we use @Singleton for our DAOs we don't inject the EntityManager >> directly but use an EntityManagerProvider which, as I understand it, is the >> correct way as the Provider is considered threadsafe which is a requirement >> for @Singleton. >> Is there a "Google approved" way to include Hibernate using DAOs in your >> web application? >> >> At what Layer would you set @Transactional? We had it on our DAO layer >> which was wrong as it led to a lot of single transactions (we are used to >> JEE where, on default, a transaction gets used if present). Now we have it >> in our Service Layer (Services, are also @Singleton which I also don't >> like...) which bundle/inject/use lots of different DAOs. Would you consider >> this to be correct to get proper transaction handling when bundling >> multiple DAOs? >> >> >> >> -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/6d41ce98-a8d1-4361-b860-003d3262aa73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
