Recursive exception and StackOverflowError in JTATransactionFactory.getUserTransaction()
by Ovidiu Feodorov
Hello there,
Is there a JIRA issue for the recursive error in
JTATransactionFactory.getUserTransaction() in 3.3.1.GA or you want me to
add one + patch?
If the UserTransaction name is invalid, NamingException is thrown
recursively by getUserTransaction() call (line 172) until the stack is full.
You probably wanted to call getUserTransactionName() instead of
getUserTransaction().
Cheers
Ovidiu
16 years, 11 months
static loggers
by Hardy Ferentschik
Hi there,
I just wanted to get some opinion on logger creation.
I introduced a LoggerFactory class into Hibernate Search which allows the
creation of Logger instances without having to specify the class. The idea
behind this it coming from this article -
http://www.javaspecialists.co.za/archive/newsletter.do?issue=137.
However, as Sanne pointed out to me, to use this pattern efficiently one
has to declare the loggers as static. In fact I am so used to this idiom
that I even dit not notice that in Search the loggers are declared as
instance variables.
After looking around a little I found these articles:
* http://www.slf4j.org/faq.html#declaration_pattern
* http://wiki.apache.org/jakarta-commons/Logging/StaticLog
Seems there are pro and cons for both approaches. The biggest drawback of
the static approach being the case where the jar is deployed as shared
library which can screw up the log output of the using applications (even
thought there seems to be ways around this).
Now, Hibernate Core seems to use static loggers. Does this mean we are not
concered about the potential drawbacks of this approach?
Should we aim for a consistent usage pattern, even across the different
Hibernate projects? Or do we maybe already have such guidelines?
--Hardy
16 years, 11 months
Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
by Manik Surtani
Weird, getInstance() was removed in early ALPHAs, and was replaced again
pretty quickly - in 3.0.0.BETA1, even.
http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main...
2008/10/18 Jason T. Greene <jason.greene(a)redhat.com>
> Brian Stansberry wrote:
>
>> Steve Ebersole wrote:
>>
>>> so JBC 3 needs this change anyway?
>>>
>>
>> Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite sure the
>> JBC team wants, since they made a bunch of other more significant changes to
>> ensure compatibility. This one's real trivial.
>>
>> at which point it would be a total
>>> drop-in replacement?
>>>
>>>
>> Yes. I just did a diff between head of trunk (which passes 100% w/ JBC
>> 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA tag and the only
>> differences are two places where the missing
>> DefaultCacheFactory.getInstance() call was replaced.
>>
>
> I fixed this compatibility problem awhile ago, but it could have been after
> CR1 was tagged.
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
16 years, 11 months
cache-jbosscache3 module for Hibernate Core
by Manik Surtani
Guys,
The API of JBC 3.0 is compatible with 2.x so the actual provider code
should not change, but we probably want to test MVCC as a locking
scheme as well.
So, we either
1) need a cache-jbosscache3 module (yuk!), copy the providers and
existing tests from cache-jbosscache2 and add a few extra tests.
or,
2) assume that cache-jbosscache2 refers to an API and not a version
of the cache. So update the cache used in cache-jbosscache2 to 3.0.0,
and add the extra MVCC tests as well.
My pref would be for 2, what do you guys think?
Cheers
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 11 months
Search: replacing lucene backend
by Sanne Grinovero
Hi, I'm ready to commit the attached patch;
(Emmanuel and Hardy Please ignore the I sent last week)
This changes the Workspace pretty much
and overwrites the lucene backend (package
org.hibernate.search.backend.impl.lucene)
with a new implementation to use the new Workspace.
so I don't think this can be split more, as it all depends on the Workspace.
Unrelated changes are already on trunk:
http://fisheye.jboss.com/changelog/Hibernate/search?cs=15224
Specifically, attached patch solves:
HSEARCH-272 Improve contention on DirectoryProviders in lucene backend
HSEARCH-263 Wrong analyzers used in IndexWriter
HSEARCH-271 Wrong Similarity used when sharing index among entities
and has some more benefits we can chat about if you like to.
There's one last change I'd like to do: changing the name from Workspace
to DirectoryWorkspace; I didn't because it would affect the OptimizerStrategy
interface but actually I just discovered this interface is not really public,
as it appears people can't provide their own strategy.
Should I do that?
Does someone have pending changes on org.hibernate.search.backend.impl.lucene ?
regards,
Sanne
2008/9/27 Sanne Grinovero <sanne.grinovero(a)gmail.com>:
> Hello,
> I managed to remove all dependencies from org.hibernate.search.backend
> to any org.hibernate.search.backend.impl in the refactoring.
>
> please let me know if you agree about committing this;
> The pattern I used is very extensible and really decouples the code,
> what I don't like from it is that it is "too clever": it's clean
> and enables very nice compile-time checks but is a bit unusual.
> Let me know if you prefer me to avoid this code style.
>
> Hope this is ok, as I would like to move on to the nice improvements
> which depend on this.
>
> Sanne
>
> 2008/9/23 Sanne Grinovero <sanne.grinovero(a)gmail.com>:
>> thanks, answers inline:
>>
>> 2008/9/23 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>> It seems fine overall.
>>> Unfortunately, your patch does not apply on trunk, so I read it through the
>>> diff file.
>> I'm sorry I shouldn't trust the eclipse plugin, we've had problems
>> before with it.
>>
>>>
>>> A couple of questions / remark:
>>> - a Workspace is now limited to a single DirectoryProvider, correct?
>> exactly
>>
>>> - why are getIndexReader / getIndexWriter and co synchronized? Is the
>>> workspace supposed to be used by different threads? It seems it should not.
>> Current backend doesn't need it, but this is the core for many optimizations.
>> This is needed for the improvements to the backend I'm working on, in
>> particular mass indexing.
>> I think it isn't hurting currently,
>> I just hope that when I'll show you the alternative backend you'll be pleased;
>> if not it's easy to just remove the synchronization and volatile.
>> Please remember that sharing IndexWriter between committing transactions
>> can have a huge scalability impact..
>>
>>> - LuceneWork (in o.h.s.backend) have a dependency on IndexInteractionType
>>> (in o.h.s.backend.impl.lucene): this seems wrong.
>>> In a way, a LuceneWork is kind of abstract from an actual Lucene work. It is
>>> propagated to all backend implementations. For example an Optimize is not
>>> propagated to JMS. So having implementation details like
>>> IndexInteractionType in LuceneWork feels bad to me.
>> Ok, I'll separate it using "visitor" pattern; expect a new patch soon.
>>
>>>
>>> The rest looks fine.
>>>
>>> --
>>> Emmanuel Bernard
>>> http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com |
>>> http://twitter.com/emmanuelbernard
>>> Hibernate Search in Action (http://is.gd/Dl1)
>>>
>>> On Sep 22, 2008, at 04:38, Sanne Grinovero wrote:
>>>
>>>> Hello,
>>>> I'm hoping you have some time to take a look on this; I think I should
>>>> commit it
>>>> but would like to hear your opinion before doing some disaster;-)
>>>> I have more features built on this "base mod".
>>>> Should I split it more? I think it's possible but it's getting hard
>>>> (and a wast of time
>>>> if you don't feel it's needed).
>>>>
>>>> Basically this does fix only HSEARCH-263 but is the base for many more
>>>> improvements.
>>>> Another change this does: a single thread never owns more than one D.P
>>>> Lock.
>>>> There's also the possibility to purgeAll() using an indexwriter, I
>>>> left out other improvements
>>>> for a later step but kept this one to "showcase" the design, meant to
>>>> enable a choice
>>>> for each work to be applied on an IndexWriter or an IndexReader
>>>> instead (when possible).
>>>> Also this affects optimization: it is only performed as last operation
>>>> (before it could be triggered
>>>> in any point) and multiple optimizations will trigger just once.
>>>>
>>>> You'll notice the Workspace being converted to a single-directory
>>>> workspace, (much simplification)
>>>> and becoming threadsafe for later improvements.
>>>>
>>>> if you like it I'll commit to trunk, so I can begin fixing actual open
>>>> issues using this as a starting point.
>>>>
>>>> regards,
>>>> Sanne
>>>>
>>>> P.S. thanks hardy for the patch you attached to 225, this is exactly
>>>> what I needed to know, I'll integrate it
>>>> in a next patch.
>>>> <Search-refactoring-step1.patch>
>>>
>>>
>>
>
16 years, 12 months
force outer-join with map collection index in where clause
by Anthony Fryer
I have a class mapped as follows... <class name="equipment" table="MSF600"> <id name="equipNo" column="EQUIP_NO"/> <map name="nameplate" table="MSF6A4" outer-join="true" fetch="join"> <key column="EQUIP_NO"/> <map-key column="ATTRIB_NAME" type="string"/> <element column="ATTRIB_VALUE" type="string"/> </map> </class> The map collection allows me to perform queries on the equipment as follows... from equipment where nameplate["TARIFF"] not in ('RU', 'BG') This works fine up until I want to do a query like this... from equipment where nameplate["TARIFF"] is null or nameplate["TARIFF"] not in ('RU', 'BG') The problem happens because hibernate performs an implicit inner join with the MSF6A4 table when it detects a nameplate[""] in the where clause. If the "TARIFF" nameplate doesn't exist, the join will not match and so no results will be returned. I know I can use... from equipment where "TARIFF" not in indices(nameplate) but still doesn't work in a combined where clause like this.. from equipment where "TARIFF" not in indices(nameplate) or nameplate["TARIFF"] not in ('RU', 'BG') because as soon as the nameplate["TARIFF"] appears, hibernate does the implicit inner join to MSF6A4 again and finds no results. I think my problem would be solved if I could force hibernate to perform an outer-join on the MSF6AF table. Is this possible? Is there some other way to get this to work?
_________________________________________________________________
16 years, 12 months
