This is the main group. Here you can get answers from developers working at guice core. I don't know of a betther place to look for answers
Am 3. Dezember 2014 11:21:50 MEZ, schrieb [email protected]: >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. -- 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/427E1572-F92C-42A6-926E-21F5C6EB7DBB%40gmx.ch. For more options, visit https://groups.google.com/d/optout.
