kdeveloper,
Comments in-line...
--Nikolaos
kdeveloper wrote:
Thanks for you're answer and I do like Stripersist, but what I need is
an easy way to work with multiple transactions in the same thread.
Okay. Although I don't have that requirement from what I see
Stripersist affords you that capability.
When you want Stripersist to manage the start and commit of the
transaction you have a choice of 3 underlying methods to leverage (as I
included in the earlier sample code):
public static EntityManager getEntityManager()
public static EntityManager getEntityManager(String persistenceUnit)
public static EntityManager getEntityManager(Class<?> forType)
When you want to include other objects outside of this automatic
transaction handling use any one of the following 2 methods:
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit)
public static EntityManagerFactory getEntityManagerFactory(Class<?>
forType)
For the latter 2 methods the docs state:
"Normally you shouldn't use this [method] (class) because Stripersist
won't clean up any EntityManagers that you create."
For example, you implement a counter that needs to be updated to the
database, independent of the fact if the action bean thinks it opportune
to store the modified model object from a form. Thus the counter, will
need it's own independent session/transaction for doing this (you don't
want to accidentally update you're model objects you use in you're view).
So if I sort of use my previous example... you could trigger some code
for the counter such as:
EntityManager manager =
Stripersist.getEntityManagerFactory("somePersistenceUnit").createEntityManager();
try {
manager.getTransaction().begin();
manager.persist(counter);
...
} catch (SomeException ex) {
manager.rollback();
}
finally {
manager.commit();
}
I haven't tested the above code but it should give you the general idea
and keep in mind Stripersist is simply assisting you in dealing with
JPA, JTA, et al... there is no reason why you can't do things yourself
OR even incorporate Spring as you were originally trying to do.
Spring transaction support this declarative, by letting annotated
methods start new transactions. These transactions will end with the end
of the method, after that you're old transaction is back in business.
Stripersist provides either automatic handling of transactions OR handle
them on your own as I have mentioned above.
Personally I would simply overload the existing framework methods with
say a boolean version that would allow me to specify if transactions are
automatic or not e.g. passing in true defaults to calling existing
methods were as false returns the entity manager or entity transaction
or whatever...
So NO... there isn't any way to OOB annotate a method that would be a
separate transaction. But I don't think this would be a very complex
exercise if you have ever created a custom annotation before.
As far as Spring declarative transaction management is concerned a lot
of people mention it however as much as AOP is wonderful and has its
uses I don't particularly care for byte code manipulation of production
code just for the ability to say look I can wrap transactions around
just about anything via some configuration / annotations and AOP byte
code manipulation. I would just rather work transactions more
explicitly into the framework of the Application code and that way when
anything simple is required there is ZERO to do and with a little extra
effort nested transactions or whatever can be handled. I also don't
particularly like all the cruft configuration code I have seen to setup
and use Spring declarative transaction management... again I have only
read about AOP and Spring declarative transaction management so I am
clearly no expert but am content with what I have w/ Stripersist and if
not that then JPA + Hibernate.
Lastly, we do use Spring heavily to wire up objects in our Apps... we
just don't need / care for Spring declarative transactions (yet ;-).
My 2 cents and YMMV... .
--Nikolaos
On 22-06-10 16:45, Nikolaos Giannopoulos wrote:
Kdeveloper,
With JPA you are responsible for starting, committing and rolling back
transactions. What does that mean - it means that the functionality is
there you just need to make the appropriate calls.
Stripersist takes care of automatically making those calls for you i.e.
Stripersist automatically starts a transaction for you. You commit it
explicitly or it gets automatically rolled back if it wasn't committed.
For example Freddy's classes have the following say 2 methods:
protected void save(T object, String persistenceUnitName) {
Stripersist.getEntityManager(persistenceUnitName).persist(object);
}
protected void commit(String persistenceUnitName) {
Stripersist.getEntityManager(persistenceUnitName).getTransaction().commit();
}
ASIDE: If you only have one persistence unit then not specifying it will
use the default.
So for example we have the following in an action bean:
this.invitee =
this.inviteeDao.findByEmail("nikol...@brightminds.org");
if (this.invitee == null) {
this.invitee = new Invitee();
this.invitee.setFirstName("Nikolaos");
this.invitee.setLastName("Giannopoulos");
this.inviteeDao.save(this.invitee);
}
Share share = new Share();
share.setUserId(this.invitee.getId());
share.setType(ShareType.PHOTO);
this.shareDao.save(share);
this.shareDao.commit(share); // Commits the full transaction!!!!
Is there something missing that you would need?
ASIDE: We have even baked Sharding on top of Stripersist and it works
quite well ;-)
The beauty of JPA + Stripersist + Hibernate is that I can focus on the
important things like Sharding and all the other stuff like persisting,
transactions, etc... requires absolutely minimal code.
HTH,
--Nikolaos
kdeveloper wrote:
On 22-06-10 0:08, Nikolaos Giannopoulos wrote:
ASIDE: I didn't really like all the work that has to be done to glue
together Spring and Hibernate and am VERY happy using Stripes with JPA,
Stripersist, and Hibernate as it allows me to focus on my Entity classes
a simple persistence.xml... . Freddy's book also has an excellent DAO
super class that heavily leverages generics so you end up with minimal
DAO code in your subclasses... .
Freddy's his DAO's are a great start. But I need an easy way to initiate
new transactions, because otherwise side effects will unintentional
result in committing model object that are used in the action beans.
I don't think Stripersist directly supports it, or am I wrong?
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
