Is there any decision taken about this?
I find the situation to have 2 major Hibernate components incompatible
after an upgrade to a point release a bit uncomfortable.
The cleanest way to fix it is probably to build a point release of
Search but if it's too much work, maybe we should just communi
Hi all,
sorry was traveling yesterday, and while I saw & merged Guillaume's
pull request, I missed this conversation.
We can to an Hibernate Search 4.4 minor release, would that resolve
all uncomforts?
The release blog would then also be an appropriate medium to warn
about the incompatibility.
S
+1 Sounds reasonable.
2013/12/6 Sanne Grinovero
> Hi all,
> sorry was traveling yesterday, and while I saw & merged Guillaume's
> pull request, I missed this conversation.
>
> We can to an Hibernate Search 4.4 minor release, would that resolve
> all uncomforts?
>
> The release blog would then a
+1
On Fri, Dec 6, 2013 at 1:15 PM, Sanne Grinovero wrote:
> Hi all,
> sorry was traveling yesterday, and while I saw & merged Guillaume's
> pull request, I missed this conversation.
>
> We can to an Hibernate Search 4.4 minor release, would that resolve
> all uncomforts?
>
> The release blog woul
So I'll get the ball rolling :) Here is one thing in particular I was
hoping to start a discussion on...
For JTA transactions we currently have a lot of complex logic to manage
who "drives" the transaction flow into Hibernate (in terms of Hibernate
reacting to the completion). There are poten
Hi Steve,
Looking at the Javadoc for
javax.transaction.Transaction.registerSynchronization(Synchronization sync), I
see:
Throws: RollbackException - Thrown to indicate that the transaction has been
marked for rollback only.
That would make it a JTA spec requirement.
More feedback coming...
The bigger question is whether we care. Is there really a benefit to
continuing work when a transaction is marked for rollback only?
On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote:
> Hi Steve,
>
> Looking at the Javadoc for
> javax.transaction.Transaction.registerSynchronization(Synchro
I think this is an excellent question, my preference is to fail-fast in
some fashion.
JTA 1.1 spec description of Transaction.setRollbackOnly():
"
public void setRollbackOnly() throws IllegalStateException, SystemException
Modify the transaction associated with the target object such that the
I'm wondering if someone might want to define such a
PreparedStatementQueryOperation just for reading data.
In such case, could there be any benefit in setting #setRollbackOnly() ?
I'm not just thinking of being paranoid to "protect" the data from
side-effects but also it could imply that the Tran
Realize that ultimately this is inended for use inside Hibernate. Thats my
only goal here. I don't care to write/maintain a general purpose JDBC
abstraction library. So I only really care in this context. Does it make
sense to continue to allow access to resources if the trabsaction is marked
f
WRT Granularity of the JDBC abstraction API...
I really like how encapsulating the operation into a
PreparedStatementQueryOperation that is executed by JdbcSession.accept(
operation ) would clean up existing code. IMO execute( operation ) would be a
better name.
It would be nice to make the re
On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
>
> It would be nice to make the return value generic:
>
> public T accept(PreparedStatementQueryOperation operation, Class
> resultClass);
95 times out of 100 inside Hibernate code we really can't take advantage
of the parameterized type.
I've been trying to sort out the relationships between JdbcSession,
Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction,
TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction.
I've only looked at the ReadMe so far. Have you started fleshing that out in
the code? I've kind o
JdbcSession is a centralization of JDBC/transaction handliong (managing
the flow of events between the 2). I picked the name as I said because
it models the concept on the database side of a session (which is a
"connection"+transaction).
TransactionCoordinator is its exposed conceptualization
It would be better to find different terms than inflow and outflow
here. The problem is that in/out depend on perspective and will be
confusing depending on which part of the code you are in. I think
better terms are:
1) transaction management or transaction driving as the process of
telling
15 matches
Mail list logo
