The way I handle this is to use a command framework, where there is a
session bean that acts as a command execution context. exception handling
like this can then be built (once) into either the command bean or session
bean. I don't find it necessary to have a different session bean remote
method for each application task.
----- Original Message -----
From: "Ampie Barnard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 6:21 PM
Subject: RE: [Hibernate] Using hibernate - best practices
> I like the services-layer idea, but also have to agree that it leads to
> repetitive code.
>
> In our system, we have implemented the service layer as session beans. The
> transaction management is taken care of by the container. But we still
have
> the repititive
> try{
> opensession();
> }catch(Exception e){
> rolbackSession();throw e;
> }finally{
> closession();
> }
> I have also simply sacrificed session propagation from one session bean to
> another.
>
> If someone were to implement the sessionFactory as a JCA connector, all
of
> this code would become the responsibility of the container. It would also
do
> the propagation of transaction contexts.
>
> As an interim solution, someone could perhaps implement a "stateless"
> version of the session factory that automatically flushes and closes
itself
> when a transaction commits, and closes when the transaction rolls back.
>
> Am I on the right track here?
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jozsa
> Kristof
> Sent: 15 November 2002 01:02
> To: Urberg, John
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Hibernate] Using hibernate - best practices
>
>
> On Thu, Nov 14, 2002 at 01:36:13PM -0600, Urberg, John wrote:
> ..
> > The InvoiceRepository would be implemented like this:
> >
> > public class HibernateInvoiceRepository {
> > public void setDatabase(Database database) { _database =
> > (HibernateDatabase) database; }
> > public List getOverdueInvoices() {
> > return database.getSession().find("<hibernate query>");
> > }
> > public void update(Object object) {
> > database.getSession().saveOrUpdate(object);
> > }
> > }
> >
>
> And where do you close those opened sessions using this design? Also,
where
> did you find a place to implement transaction handling, including joining
> into existing transactions if possible?
>
> I have my own pieces of ideas how to implement a design for Hibernate, but
> I'm fighting with the questions listed above too. Got some workaround, but
> kinda far from being perfect.. Mainly I used Ralf's third possible
solution
> from these:
>
> > > * Put everything into the domain classes.
> > > * Implement something like a "Home" interface
> > > * Implement some sort of component-like / "Service" interface
>
> ..having a layer of 'service-like' components in charge of
database-related
> operations, which either use Hibernate (98%) or plain JDBC pulling the
> connection from a Hibernate session. These components are always pulled by
> the upper layer from a plain component pool, which I implemented myself.
But
> mentioning one returning problem, I have *LOTS* of repeated code parts
like
> these:
>
> Session session = null;
> Transaction tx = null;
> try {
> session = Hibernator.getSession(); // my custom class which keeps
> the sessions and initializes Hibernate
> tx = session.beginTransaction();
> ..
> ..
> tx.commit();
> } catch (Exception e) {
> logger.error (<blah/>), e);
> tx.rollback();
> // rethrow business-exception if suitable
> } finally {
> if (session != null) session.close();
> }
>
> These piece of codes are repeating in almost ALL of the Service classes'
> business methods, are just flooding all the logic badly :( (ok, tx
handling
> is missing from this where i'm doing read-only operations, but still..) I
> also have some part-solution related to joining to existing transactions,
> but I find it snappy too.
>
> So, as I said, I don't feel my design good at all.. just couldn't find out
> any better for the moment. Therefore, I'd be very happy and thankful to
read
> about others experiences and concrete architecture/design plans.
>
> Regards,
> dyn
> --
> .Digital.Yearning.for.Networked.Assassination.and.Xenocide
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> hibernate-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> hibernate-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
