> session.flush();
> session.clear();
> hibernateSessionManager.commit();
This is wrong.
First on commit you will do the flush automatically (flush means all
changes are written to the database (performing outstanding updates,
inserts, deletes))
Clear clears the persistence context of all entities not taking part on any
outstanding flush event (as far as I remember) therefore Hibernate does a
deep
inspection of the active entities and removes all entities that were not
encountered during that process.
Commit commits the entities.
So the correct usage is:
session.getTransaction().commit();
session.clear();
session.beginTransaction();
(without the clear its what HibernateSessionManager is doing with the
session bound to the current thread).
2013/10/25 Martin Kersten <martin.kersten...@gmail.com>
> Use:
>
> @Inject
> Session session; //current session bound to the current thread
>
>
> or
>
> @Inject
> HibernateSessionSource source; + source.create() for a really new session
> (CommitAfter would not work with newly created one);
>
> Using the Manager does give you only the session associated with the
> current thread as would @Inject Session session; would do.
>
>
>
>
> 2013/10/25 George Christman <gchrist...@cardaddy.com>
>
>> So I guess I'm still a little confused as to what is the best to do it.
>> @CommitAfter seems to work fine for individual transactions but does not
>> work well with batch jobs do to it holding on to the object in memory.
>> Anyhow, I could not figure out how to get Martins session.getTransaction()
>> to work, however I did end up getting the following code to work. Could
>> someone tell me if I'm doing this correctly? Also should I be closing and
>> rolling back the transaction?
>>
>> //Mock scenario
>>
>> @Inject
>> private HibernateSessionManager hibernateSessionManager;
>>
>> public void onActionFromTest() {
>> Session session = hibernateSessionManager.getSession();
>>
>> for (int i = 0; i < 100000; i++) {
>> employee = new Employee("George " + i);
>>
>> session.save(employee);
>>
>> if (i % 250 == 0) {
>> session.flush();
>> session.clear();
>> hibernateSessionManager.commit();
>> }
>> }
>>
>> session.flush();
>> session.clear();
>> hibernateSessionManager.commit();
>>
>>
>>
>> On Fri, Oct 25, 2013 at 9:07 AM, Thiago H. de Paula Figueiredo <
>> thiag...@gmail.com> wrote:
>>
>> > On Fri, Oct 25, 2013 at 10:53 AM, Barry Books <trs...@gmail.com> wrote:
>> >
>> > While it's true you can run into problems by nesting @CommitAfter the
>> same
>> > > can be said about nesting any commits. The Tapestry database model is
>> > > simple. There is one connection per request and when you call commit
>> it
>> > > does a commit.
>> > >
>> >
>> > <pedantic>
>> > Tapestry itself doesn't have any database model. It's a web framework
>> and
>> > nothing else. You can use it with any database, including none.
>> > Tapestry-Hibernate is a package that provides *simple* support for
>> > Hibernate and should be used in *simple* scenarios. If you need
>> something
>> > that's not simple, like any transaction handling not supported by
>> > @CommitAfter, use Tapestry and some transaction handler (EJB, Spring-TX,
>> > etc) but not Tapestry-Hibernate.
>> > </pedantic>
>> >
>> >
>> >
>> > >
>> > >
>> > > On Fri, Oct 25, 2013 at 7:31 AM, Lance Java <
>> lance.j...@googlemail.com
>> > > >wrote:
>> > >
>> > > > I'm assuming a fork is broken too because it's no good for eating
>> soup?
>> > > > Sounds like you need a spoon, it's easy to write your own
>> annotation...
>> > > > Perhaps you want a @MaybeCommitAfter ;)
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Thiago
>> >
>>
>>
>>
>> --
>> George Christman
>> www.CarDaddy.com
>> P.O. Box 735
>> Johnstown, New York
>>
>
>
