>>>> what issue do you have with this.
>>> The main issue is that this relies on:
>>> 1) when the call is made
>>> 2) the classloader layout of the environment in which the call occurs.
>>> OSGI comes to mind in
that long; lets see how things go.
>
> In the meantime, I moved all unresolved issues not in progress to 3.5.x.
>Please take the time asap to mark any issues you want in 3.5.0-CR-2.
> I completely expect this to be the last CR before 3.5.0
>
> Thanks
>
--
Brian Stansb
>> I can totally see how a wildfly instance could download
>>> these on-demand from the dependency definition; by having these in
>>> Maven, corporate environments might not dislike it too much as they
>>> could have their own repository managers.
>>
>> Now that is different imo. Now we provide some proper tooling around this.
>> When are you having this ready to go?
>
> I think we could ask for help to make better tooling, if we have a
> case. We won't get tooling to deploy modules if we don't make the
> modules and verify this is a good plan. Ideally I'd like WildFly to
> automatically download extensions, so we can blame the app server for
> "downloading the internet" :)
>
As mentioned above, this kind of thing is under
consideration for the long term roadmap.
>>> BTW this problem is only for JBoss / Wildfly as other app servers
>>> don't bundle Hibernate, so the solution is special purpose as well.
>>
>> So basically we are saying on our app server it is actually harder to get
>> this to work than on
>> others. Interesting. Maybe we should target Glassfish then.
>
> We should target them all, including WildFly even if it needs an
> additional zip :-)
> BTW only WildFly would be able to address the monitoring, Infinispan
> and mod_cluster integrations appropriately, at least until others
> won't expose similar capabilities and modularity.
>
> -- Sanne
>
>>
>> --Hardy
>>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
timestamps cache would still replicate.
Do you guys see any problem with such an approach (besides ugliness);
e.g. any problems with the non-replicated query caches falling out of
sync with the entities?
- Brian
Brian Stansberry wrote:
> Steve Ebersole wrote:
>> (1)
>>
>> Th
xecutives: Red Hat still #1 for value
> http://www.redhat.com/promo/vendor/
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Brian Stansberry
> Sent: 17 November 2006 16:44
> To: Manik Surtani
> Cc: [EMAIL PROTECT
rs, but this is different topic
>>> already... +:-)
>>>
>>> I sent an email a month ago about the possibility of creating a
>>> Hibernate/JBC compatibility matrix but not a single person replied.
>>> These tests would give us the information we need fo
0 100 5202
Manik Surtani wrote:
+1
On 22 Feb 2007, at 18:19, Steve Ebersole wrote:
Brian Stansberry wrote:
Sent this out a while back, but the conf call didn't come off due to
scheduling issues. Time to try again.
How does next Monday, Feb 26 at 10:00 AM EST sound? Once we have an
a
k with more details here, but general consensus
is not to perform transparent retries.
Feel free to add stuff I may have missed or further thoughts.
Very useful and productive call!
Cheers,
Manik
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
[EMAIL PROTECTED]
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
within the given JBossCache TreeCache.
+ * Subclass of the standard org.hibernate.cache.TreeCache used as
+ * a workaround until issues related to JBCLUSTER-150 are resolved in
Hibernate.
*
* @author Gavin King
+ * @author Brian Stansberry
*/
-public class TreeCache implements Cache {
+public
he TC/TM, you instead delegate it
to a strategy which can route the request back through Hibernate;
Hibernate can then manage ordering the callbacks?
I don't recall more progress on that topic.
Don't forget this one - manik ? :)
I think he's teaching this week??
--
Brian Stans
lexibility to call a different method for the
UpdateTimestampsCache call; to fix the problem we need determine the
exact behavior we want for the UpdateTimestampsCache call and make the
appropriate call to JBC.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a divisi
Christian Bauer wrote:
On Jul 2, 2007, at 4:58 PM, Brian Stansberry wrote:
FYI, there are a bunch of EJB3 clustered entity test failures in AS
trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss
Cache 2.0.0. Basically, this is a temporary mismatch between
Hibernate and JBC
internal timestamp map, and just
uses JBC as a replication layer. No change is allowed to the internal
timestamp map unless it *increases* the timestamp.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
[EMAIL PROTECTED]
___
hibernate-dev
preInvalidate() and then pass it back. Likely
requires a change to Executable to provide a holder for it.
A change to the TimestampsRegion API has no benefit without a
corresponding change in UpdateTimestampsCache and its caller.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a divisi
he cached query will just result in it being discarded as out
of date anyway.
4) Timestamps
Here you don't want an RR semantic. You always want to get the most
up-to-date data.
Anyone see any holes in my thinking?
--
Brian Stansberry
Lead, JBoss AS Clustering
JBoss, a
2008-07-17 at 12:59 -0500, Brian Stansberry wrote:
Can anyone see a reason to use REPEATABLE_READ as the JBoss Cache
isolation level in the 2nd level cache use case? I'm not seeing one, and
it certainly hurts performance by forcing cache writes to block waiting
for an earlier tx that did
27;s a bit more subtle than that.
I did neglect to change the default in the AS 5 / Hib 3.3 config files,
which will shortly be corrected.
On 17 Jul 2008, at 22:59, Brian Stansberry wrote:
Hmm, good point. Potentially also Session.refresh(...), although I'm
not sure if the implementation
gic is
complex. (Agreed, if it happens a lot that's a sign of a design flaw in
the app.) But to then expect R_R from the second read: that for sure
makes it an edge case.
Brian, did you use 2nd level cache in your previous use case?
No.
On Thu, 2008-07-17 at 16:59 -0500, Brian Stansbe
Manik Surtani wrote:
On 18 Jul 2008, at 16:35, Brian Stansberry wrote:
Galder Zamarreno wrote:
Paul Ferraro wrote:
refresh() always goes to the db, and only potentially triggers a 2LC
update - not a read.
[OT] A concern I have is whether the refresh() removes the item from
the 2LC
.jboss.org/mailman/listinfo/hibernate-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
[EMAIL PROTECTED]
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
TED]
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Mon, 2008-10-13 at 09:18 -0500, Brian Stansberry wrote:
Manik Surtani wrote:
Guys,
The API of JBC 3.0 is compatible with 2.x so the actual provider code
sh
Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Fri, 2008-10-17 at 16:48 -0500, Brian Stansberry wrote:
Just ran the current trunk testsuite for cache-jbosscache2 using JBC
3.0.0.CR1 and there are no problems.
However, there are a 21 failures trying to use 3.0.0.CR1
boss/cache/DefaultCacheFactory.java?r=6676
2008/10/18 Jason T. Greene <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
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&#x
e, don't decide the
impossible is the answer. Look again and see the blindingly obvious
possible answer. :-)
Brian Stansberry wrote:
Sorry, Manik, tests were failing w/ NoSuchMethodError and I saw your
recent change in hibernate trunk to remove use of
DefaultCacheFactory.getInstance() an
cache. There is no legacy usage to support like there was with
JBC2. And if people want a shared cache, we can revisit.
> Finally, a question to the list, specially for Brian/Steve who worked on
> the JBC2/3 integration layer:
>
> - Do we n
The ugly bit is that works if people configure a region name for their
entities, rather than using the default fully qualified class name. I
suppose the fully qualified class name could work as well, just a bit
more parsing.
>
> Cheers
> --
> Manik Surtani
> ma...@jboss.org <mailto:ma...@jboss.org>
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Got distracted and hit send early last time...
Brian Stansberry wrote:
> Manik Surtani wrote:
>>
>> On 4 Aug 2009, at 14:02, Galder Zamarreno wrote:
>>
>>>>
>>>> s/region.ispn4/infinispan
>>>
>>> Ok.
>>>
>>> One
Galder Zamarreno wrote:
>
>
> On 08/04/2009 06:23 PM, Brian Stansberry wrote:
>> Got distracted and hit send early last time...
>>
>> Brian Stansberry wrote:
>>> Manik Surtani wrote:
>>>>
>>>> On 4 Aug 2009, at 14:02, Galder Z
Galder Zamarreno wrote:
>
>
> On 08/04/2009 06:40 PM, Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>>
>>>
>>> On 08/04/2009 06:23 PM, Brian Stansberry wrote:
>
>
>
>>>>
>>>> Also, unless there's a really g
Galder Zamarreno wrote:
>
>
> On 08/05/2009 04:04 PM, Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>>
>
>>>
>>
>> Sounds like this has diverged quite a bit from the JBC integration then.
>> In your initial message you were discussin
or the timestamps cache and this is something that could be validated
> on startup, that eviction strategy is NONE.
>
+1.
> Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> infinispan-dev mailing list
>>> infinispan-...@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> ma...@jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
It's semi-maintained, but TBH it seems rather convoluted and thus
fragile.
I've opened https://jira.jboss.org/jira/browse/JBAS-7411 for this and
will post a link to that on the stackoverflow thread.
There's a deployer that parses a hibernate.cfg.xml into a metadata
object, which includes th
FYI, this has been fixed in JBoss trunk.
On 10/28/2009 09:25 PM, Brian Stansberry wrote:
> It's semi-maintained, but TBH it seems rather convoluted and thus fragile.
>
> I've opened https://jira.jboss.org/jira/browse/JBAS-7411 for this and
> will post a link to that on th
,
> minutes...etc
>
> The reason I think JMX is a good candidate here is this is inherently
> monitoring information and it allows us to expose internal information
> via primitives without having to expose internal classes.
>
> Thoughts?
>
> Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
;
> http://snapshots.jboss.org/maven2/org/infinispan/infinispan-core/4.0.0-SNAPSHOT/infinispan-core-4.0.0-20091130.165452-15-tests.jar
>
> - Juca.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://li
nard wrote:
>>>> Steve,
>>>> Do you think there is enough material / bug fix to cut another beta
>>>> for inclusion in AS 6 M2?
>>>> Something like a 2 weeks target.
>>>>
>>>>
>>>> On my side that would make sens
37 matches
Mail list logo
