[ISPN-6] COMMITTED tx status handling changed from JBC to ISPN
by Galder Zamarreno
Hi all,
More stuff related to the infinispan cache provider. The way we deal
with transactions that are not ACTIVE or PREPARING has changed from
JBoss Cache to Infinispan.
In JBoss Cache, TransactionTable.getCurrentTransaction() logged a
message if the transaction's status was committed whereas Infinispan
simply throws an IllegalStateException if the status is neither ACTIVE
nor PREPARING.
This change of behaivour is making Infinispan cache provider tests that
do bulk modifications to fail. The reason it fails is because Hibernate
has a javax.transaction.Synchronization implementation called
CacheSynchronization that in it's afterCompletion(), it leads to call
BulkOperationCleanupAction.evictEntityRegions() which clears the cache
for the affected entities. Now, since the tx status is COMMITTED, the
test fails.
Would there be any problems in maintaining the previous logic?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 10 months
Is Eclipse RCPed application including hibernate library covered under LGPL?
by Keiko Murakami
Hi everyone,
I've been developing an application related Eclipase with hibernate
libarary.
When I build the application as RCP file that includes hibernate library,
should I distribute it under LGPL?
I read LGPL v2.1 section 5, I know my application in isolation is
"work that uses the Library(hibernate)",
but my concern is that RCPed application(executable form)
must be applied LGPL,
because it includes full hibernate library as jar files and
its hibernate library can not separate from RCPed application.
I'm not sure whether this is the right place to ask,
but I appreciate your help.
Thank you,
Keiko
16 years, 10 months
Delivery reports about your e-mail
by MAILER-DAEMON
Dear user of lists.jboss.org,
We have detected that your e-mail account has been used to send a huge amount of unsolicited email during the last week.
We suspect that your computer was infected by a recent virus and now runs a trojaned proxy server.
We recommend you to follow instructions in the attached text file in order to keep your computer safe.
Virtually yours,
lists.jboss.org user support team.
16 years, 10 months
Message could not be delivered
by Returned mail
The original message was received at Sat, 15 Aug 2009 19:34:42 +0530
from 73.114.52.69
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
16 years, 10 months
Mail System Error - Returned Mail
by Mail Delivery Subsystem
Your message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 5 days:
Mail server 157.43.231.211 is not responding.
The following recipients did not receive this message:
<hibernate-dev(a)lists.jboss.org>
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
16 years, 10 months
Infinispan cache loaders in Hibernate Search
by Łukasz Moreń
Infinispan offers several persistance stores to persist content of cache,
i.e. based on file system, database, S3 amazon service. Is there some
recommendation which one should be used as a default for Hibernate Search
directory provider based on Infinispan cache?
What about cache loaders configuration strategy: one cache store per node,
one common store for all nodes, only single node allowed to write to
persistance store.
Maybe one common store is the right one.
Cheers
Lukasz Moren
16 years, 10 months
3.5.0-beta1
by Steve Ebersole
Heads up that I will be doing the first beta release for 3.5 tomorrow.
In support of that I will also be cutting a beta release of
org.hibernate.java-persistence:jpa-api.
Cheers.
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years, 10 months
Re: [hibernate-dev] [infinispan-dev] Infinispan tx, config and multithreading
by Łukasz Moreń
Newly created threads were not associated with any transaction, so I
suppose it was a problem. Sharing transaction between threads seems to
be a good solution.
Thanks for help!
2009/8/13, Jason T. Greene <jason.greene(a)redhat.com>:
> Correct. Also there could be read races as well, so if you are going to
> share a tx between threads, i would use some shared lock to gaurantee
> that only one thread can use it at a time. BTW this means you have to
> properly suspend/resume the TX via the TM API as well.
>
> Emmanuel Bernard wrote:
>> Modifying a transaction means applying muations (like SQL INSERT /
>> UPDATE / DELETE) to the transactional resource?
>>
>> On 13 août 09, at 15:07, Jason T. Greene wrote:
>>
>>> When using transactions, the context is bound to the transaction, and
>>> you can move a transaction between threads. However, you should only
>>> be modifying a transaction with one thread at a time.
>>>
>>> Emmanuel Bernard wrote:
>>>> Could it be that you are not using the same transaction between
>>>> different threads (ie you physically start different ones or
>>>> different "Infinispan contexts")?
>>>> Infini guys, do you support transactional operation spanning several
>>>> concurrent threads?
>>>> On 13 août 09, at 14:04, Łukasz Moreń wrote:
>>>>> I've tried with JBoss AS transaction manager and JBossStandaloneTM.
>>>>> The result is this same in all cases - error during merge.
>>>>>
>>>>> 2009/8/12, Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>>>> Ok I understand better now.
>>>>>> Do your tests in JBoss AS with it's decent transaction manager
>>>>>> (infinispan should have a config for it)
>>>>>> For unit testing, force the indexing process in hibernate to use a
>>>>>> single thread (I ghnk it's possible ask Sanne of you don't know how).
>>>>>>
>>>>>> Exposing some configuration to infinispan makes sense. can you
>>>>>> start a
>>>>>> thread explainig what is configurable and which one you think we
>>>>>> should expose to hsearch users. Ideally I would like to offer one or
>>>>>> two defaut config scenarios and allow to fallback to a custom config.
>>>>>>
>>>>>> Emmanuel
>>>>>>
>>>>>> On 12 août 2009, at 11:58, Łukasz Moreń <lukasz.moren(a)gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sorry, but my wifi does not work well today. I will try to explain
>>>>>>> it more clear.
>>>>>>>
>>>>>>> I'm using DummyTransactionManager available for Infinispan.
>>>>>>> It associates transaction with the calling thread.
>>>>>>>
>>>>>>> Steps to update index:
>>>>>>>
>>>>>>> 1. index writer acquires lock - begin of transaction
>>>>>>>
>>>>>>> 2. if it is necessary, index writer delegates new threads to do
>>>>>>> merge work.
>>>>>>> Those merge threads do not see changes made so far from begin of
>>>>>>> transaction,
>>>>>>> and are looking for segments which are not yet in index.
>>>>>>> Changes will be visible when AD.3 is completed.
>>>>>>> For tests i tried to commit transaction when merge starts and then
>>>>>>> everything worked well. But then i need to start it again.
>>>>>>>
>>>>>>> 3. index writer releases lock - transaction is commited, all changes
>>>>>>> made in this transaction are visible for other threads.
>>>>>>>
>>>>>>> Maybe using some other transaction manager could help?
>>>>>>>
>>>>>>> What about Infinispan cache configuration? Some configuration
>>>>>>> mechanism should be exposed to the user,
>>>>>>> or we can hardcoded one in InfinispanDirectoryProvider is enough?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2009/8/12 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>>>>>> why?
>>>>>>> Emmanuel Bernard
>>>>>>> Pending
>>>>>>> you there?
>>>>>>> Emmanuel Bernard
>>>>>>> Pending
>>>>>>> Ok please describe in details what is going on. From what you are
>>>>>>> describing the tx cannot see all segments which looks like an
>>>>>>> infinispan bug to me.
>>>>>>> Pending
>>>>>>>
>>>>>>> As a back up you can try wo transaction and see if that works
>>>>>>> Emmanuel Bernard
>>>>>>> Pending
>>>>>>> technically the lucene index should cope with that
>>>>>>> Emmanuel Bernard
>>>>>>> 11:16
>>>>>>> but I like this approach less
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let's try and chat by email IF I'm not online, I need to run on some
>>>>>>> errands today.
>>>>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> --
>>> Jason T. Greene
>>> JBoss, a division of Red Hat
>>
>
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
>
16 years, 10 months
Delivery reports about your e-mail
by Automatic Email Delivery Software
S��cm����;e�H����
�����n����w{�/�����
���q�>���}�����
sY{��D���%���$���%)���D�o�����%K��O����(�i��Ci`�)�d�m��nx��3�I_�:��Dq������_1�T�Z�J�E�����&��������%�od-T�P������42���BF���d�sU��TW ���T�����!����xl�`�����d}&�E�D?�,
���<�W�[U����3�4�n������z���` yVr�~k`/0"AI������b�m����Lb�<�G�X��f�E6BH$�
16 years, 10 months
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
by Galder Zamarreno
Hi Brian,
Of my original email, there's a section that I don't think has been
answered yet
On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
> Finally, a question to the list, specially for Brian/Steve who worked on
> the JBC2/3 integration layer:
>
> - Do we need a similar timestamp region local cache implementation for
> an ISPN based cache provider?
>
> Cheers,
This question focuses on the TimestampsRegionImpl (and potentially
ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x
integration layer. Is there a need for a similar region implementation
for Infinispan? I'm not sure I fully understand the need for
TimestampsRegionImpl to manage this local cache.
Talking about timestamps, I assume that no evictions should ever happen
for the timestamps cache and this is something that could be validated
on startup, that eviction strategy is NONE.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 10 months
