Hello everybody
I found that after migrating from 4.2.8.Final to 4.3.0.Final, if I have
several @OneToMany EAGER entity relations and select at least 500 rows I
get ORA-01000: maximum open cursors exceeded JDBC exception for Oracle
database (ojdbc 12.1.0.1)
I think problem is in
org.hibernate.loa
The meetings are uploaded - it's just that jirabot looses the connection while
that is happening so it doesn't get to tell it.
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-01-21-16.04.html
I got a fix cooked up i think should make things better. I'
So for today's meeting, jbott has still not ended the meeting. And
that was 4 hours ago. At least it has not responded with the URLs. Is
it still going?
On Tue 21 Jan 2014 09:11:08 AM CST, Steve Ebersole wrote:
> The issue with slowness of ending the meeting was annoying yes.
> Thanks for fi
The issue with slowness of ending the meeting was annoying yes. Thanks
for finding that.
The other issue is that jbott is sometimes just not there. It drops
off quite a bit. To give you a flavor, here is its drops from just
yesterday:
01:44 *** jbott has quit
IRC (Ping timeout: 272 second
On 21 January 2014 13:25, Gunnar Morling wrote:
> 2014/1/21 Sanne Grinovero
>>
>> I don't know if that's explicitly defined in the spec, but even if it
>> wasn't I wouldn't be happy as a user to see an exception for such a commonly
>> used feature.
>
> So you prefer to silently use another strate
so I found whats wrong - the jbott been running for 4 years and one of
the things it does when ending meetings is regenerating indexes that
was fast the first couple of yearsnow its turned "slow" because it
happens sequentially ;)
I'll see what I can do to fix that dumb logic.
/max
> We have been having a lot of trouble lately with relying on jbott to
> record the team meetings on irc. A few times jbott has not been in
> the
> room. A few times it refuses to start/end meetings.
>
> Max, is there anything to be done to make jbott more stable?
jbott had been running for mo
2014/1/21 Sanne Grinovero
> I don't know if that's explicitly defined in the spec, but even if it
> wasn't I wouldn't be happy as a user to see an exception for such a
> commonly used feature.
>
So you prefer to silently use another strategy than the one configured
instead of reporting the issue?
I don't know if that's explicitly defined in the spec, but even if it
wasn't I wouldn't be happy as a user to see an exception for such a
commonly used feature.
Clearly when such an ID is requested we need to invoke the server out of
the batching / transaction context, which might be a suboptimal
