The main reason is because allowing these exceptions to be (re-)thrown
opens up mixed heuristic issues.
Also bear in mind that we have no clue about the nature of the process
being performed by the synch. It highly likely that "failure" of the
synch should *not* rollback the main transaction.
In regards to
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 I
have taken a look at the test case. The issue comes from a property
that annotation-binder is generating that I have no idea why it is.
Specifically, take a look at the comment:
http://opensource.atlassian.com/p
Hi!
The sync is actually rolling back the main transaction, but there is no way
to indicate upper layers about it because hibernate calls commit()
succesfully after syncs.
Could we think about adding a new exception to be throwed by the
JDBCTransaction? In that case this exception is thrown by a s
Hi guys
I'm thinking of translating the entire Hibernate Core manual to
spanish, what are the steps?.
Thanks in advance
--
Lcdo. Wilfredo Rafael Rodríguez Hernández
msn,googletalk = wilfre...@gmail.com
cv = http://www.wilfredor.co.cc
blog
Hello,
> The main reason is because allowing these exceptions to be (re-)thrown
> opens up mixed heuristic issues.
>
> Also bear in mind that we have no clue about the nature of the process
> being performed by the synch. It highly likely that "failure" of the
> synch should *not* rollback th
Little more info. The generated property is coming from
BinderHelper.createSyntheticPropertyReference as called from
org.hibernate.cfg.ToOneFkSecondPass#doSecondPass
The mappings in question here are:
public class Company {
@Id
@Column(name = "entity_id")
@GeneratedValue(strateg
