hibernate-devel — development

Re: [Hibernate] DistributedCacheConcurrencyStrategy implemented !

[Gavin K. <ga...@ap...>]

Sorry for not following this closely today. I am in the middle of a massive
(and long overdue) refactor of Hibernate (that does not affect the cache
package). I will pay closer attention to this once I am done with the
refactor.

peace...

----- Original Message -----
From: "Christian Meunier" <vc...@cl...>
To: <hib...@li...>
Sent: Tuesday, September 24, 2002 12:38 AM
Subject: [Hibernate] DistributedCacheConcurrencyStrategy implemented !


> Hi all, got a little time today to investigate Gavin proposition about
> the DistributedCacheConcurrencyStrategy.
> Here is a first shoot, it's based on javagroups to manage a distributed
> lock server ( block provided by javagroup ;) )
>
> Since the lock server is distributed, even if one or more server in the
> cluster fail, the rest can still use the cache.
>
> I used the latest javagroups version available with log4j
> (JavaGroups-2.0.3.log4j.bin.zip).
> Few little things need to be done like using the mutators to set the
> multicast adr / port.
>
> Give it a try , it's fun ;)
>
> Chris
>


----------------------------------------------------------------------------
----


> package cirrus.hibernate.cache;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> import org.javagroups.blocks.LockNotGrantedException;
> import org.javagroups.blocks.LockNotReleasedException;
> import org.javagroups.ChannelException;
>
>
> public class DistributedCacheConcurrencyStrategy implements
CacheConcurrencyStrategy
> {
>     private final CacheConcurrencyStrategy cacheConcurrencyStrategy;
>     private static final Log log =
LogFactory.getLog(DistributedCacheConcurrencyStrategy.class);
>
>     public DistributedCacheConcurrencyStrategy(CacheConcurrencyStrategy
cacheConcurrencyStrategy)
>     {
>         this.cacheConcurrencyStrategy = cacheConcurrencyStrategy;
>     }
>
>
>     public Object get(Object key, long txTimestamp) throws CacheException
>     {
>         Object cachedItem = null;
>         try
>         {
>             DistributedLockServer.getInstance().lock(key);
>             cachedItem = cacheConcurrencyStrategy.get(key,txTimestamp);
>             DistributedLockServer.getInstance().unlock(key);
>         }
>         catch (LockNotGrantedException e)
>         {
>             // The object is already locked
>             if(log.isDebugEnabled()) log.debug("Could not acquire lock on
object: "+key);
>         }
>         catch (ChannelException e)
>         {
>             log.error(e);
>         }
>         catch (LockNotReleasedException e)
>         {
>             log.warn(e);
>         }
>         return cachedItem;
>     }
>
>     public boolean put(Object key, Object value, long txTimestamp) throws
CacheException
>     {
>         boolean isItemCached = false;;
>         try
>         {
>             DistributedLockServer.getInstance().lock(key);
>             isItemCached =
cacheConcurrencyStrategy.put(key,value,txTimestamp);
>             DistributedLockServer.getInstance().unlock(key);
>         }
>         catch (LockNotGrantedException e)
>         {
>             // The object is already locked
>             if(log.isDebugEnabled()) log.debug("Could not acquire lock on
object: "+key);
>         }
>         catch (ChannelException e)
>         {
>             log.error(e);
>         }
>         catch (LockNotReleasedException e)
>         {
>             log.warn(e);
>         }
>         return isItemCached;
>     }
>
>     public void lock(Object key) throws CacheException
>     {
>         try
>         {
>             DistributedLockServer.getInstance().lock(key);
>             cacheConcurrencyStrategy.lock(key);
>             DistributedLockServer.getInstance().unlock(key);
>         }
>         catch (LockNotGrantedException e)
>         {
>             // The object is already locked
>             if(log.isDebugEnabled()) log.debug("Could not acquire lock on
object: "+key);
>         }
>         catch (ChannelException e)
>         {
>             log.error(e);
>         }
>         catch (LockNotReleasedException e)
>         {
>             log.warn(e);
>         }
>     }
>
>     public void release(Object key) throws CacheException
>     {
>         try
>         {
>             DistributedLockServer.getInstance().lock(key);
>             cacheConcurrencyStrategy.release(key);
>             DistributedLockServer.getInstance().unlock(key);
>         }
>         catch (LockNotGrantedException e)
>         {
>             // The object is already locked
>             if(log.isDebugEnabled()) log.debug("Could not acquire lock on
object: "+key);
>         }
>         catch (ChannelException e)
>         {
>             log.error(e);
>         }
>         catch (LockNotReleasedException e)
>         {
>             log.warn(e);
>         }
>     }
> }
>


----------------------------------------------------------------------------
----


> package cirrus.hibernate.cache;
>
> import org.javagroups.JChannel;
> import org.javagroups.ChannelException;
> import org.javagroups.ChannelClosedException;
> import org.javagroups.blocks.*;
> import org.javagroups.blocks.DistributedLockManager;
>
> public class DistributedLockServer
> {
>     private static DistributedLockServer singleton = new
DistributedLockServer();
>
>     private String multiCastAdr = "228.3.11.76";
>     private String multiCastPort = "12345";
>
>     private String SERVER_PROTOCOL_STACK = ""
>         +
"UDP(mcast_addr="+multiCastAdr+";mcast_port="+multiCastPort+";ip_ttl=32;"
>         + "mcast_send_buf_size=150000;mcast_recv_buf_size=80000)"
>         + ":PING(timeout=500;num_initial_members=1)"
>         + ":FD"
>         + ":VERIFY_SUSPECT(timeout=1500)"
>         + ":pbcast.STABLE(desired_avg_gossip=200)"
>         +
":pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800)"
>         + ":FRAG(frag_size=4096)"
>         + ":UNICAST(timeout=5000)"
>         + ":pbcast.GMS(join_timeout=5000;join_retry_timeout=1000;"
>         +     "shun=false;print_local_addr=false)";
>
>     private JChannel channel;
>     private VotingAdapter adapter;
>     private LockManager lockManager;
>     private int lockTimeout;
>
>     // Compute unique identity
>     private String identity = ""+System.currentTimeMillis();
>
>     private DistributedLockServer()
>     {
>         try
>         {
>             channel = new JChannel(SERVER_PROTOCOL_STACK);
>             adapter = new VotingAdapter(channel);
>             channel.connect("voting");
>         }
>         catch (ChannelException e)
>         {
>         }
>         catch (ChannelClosedException e)
>         {
>         }
>
>         lockManager = new
org.javagroups.blocks.DistributedLockManager(adapter, "1");
>         lockTimeout = 5000;
>     }
>
>     public static DistributedLockServer getInstance()
>     {
>         return singleton;
>     }
>
>     public void setMultiCastAdr(String multiCastAdr)
>     {
>         this.multiCastAdr = multiCastAdr;
>     }
>
>     public void setMultiCastPort(String multiCastPort)
>     {
>         this.multiCastPort = multiCastPort;
>     }
>
>     public void setLockTimeout(int lockTimeout)
>     {
>         this.lockTimeout = lockTimeout;
>     }
>
>
>     public void lock(Object key) throws LockNotGrantedException,
ChannelException
>     {
>         lockManager.lock(key,identity,lockTimeout);
>     }
>
>     public void unlock(Object key) throws LockNotReleasedException,
ChannelException
>     {
>         lockManager.unlock(key,identity);
>     }
> }
>

[Hibernate] DistributedCacheConcurrencyStrategy implemented !

[Christian M. <vc...@cl...>]

Hi all, got a little time today to investigate Gavin proposition about 
the DistributedCacheConcurrencyStrategy.
Here is a first shoot, it's based on javagroups to manage a distributed 
lock server ( block provided by javagroup ;) )

Since the lock server is distributed, even if one or more server in the 
cluster fail, the rest can still use the cache.

I used the latest javagroups version available with log4j 
(JavaGroups-2.0.3.log4j.bin.zip).
Few little things need to be done like using the mutators to set the 
multicast adr / port.

Give it a try , it's fun ;)

Chris

Re: [Hibernate] JCS cache - Distributable read-write

[Christian M. <vc...@cl...>]

Little more thought on this subject ;)

Like i said in a previous mail, i understand fully now what Gavin is doing
(and why he is doing it) with the ReadWriteCache implementation.

However i believe such implementation which is 100% safe got some tradeoff
( each method are synchronized ), i am under the impression (Wrong ?) that
for a web based application (only pretty short transaction / if a tx begin
at t0 it will end before a tx that started at t1)  that do not manage
sensitive information like banking records  such security level is a bit
overkill.

It could be usefull in such case to be able to use a lightweight version of
the ReadWriteCache that does not need to synchronize each of its method. It
will ensure the best performance and can be distributed with a jcs lateral
caching.

I am think about this:

(1) Coarse grained approach : configure hibernate to use a custom
CacheConcurrencyStrategy for every cached class:

Something like this in the hibernate properties:

hibernate.jcs_cache.read_only_concurrency_strategy
cirrus.hibernate.cache.ReadOnlyCache
hibernate.jcs_cache.read_write_concurrency_strategy
cirrus.hibernate.cache.ReadWriteCache

(2) Fine grained approach : enhance the <jcs-cache> to support a
concurrency-strategy attribute:

Something like this in the metadata info:

<class name="eg.Foo">
      ....
     <jcs-cache usage="read-write"
concurrency-strategy="cirrus.hibernate.cache.ReadWriteCache"/>
</class>


What do you think about this ?

Regards
Chris

Re: [Hibernate] iterator docs

[Gavin K. <ga...@ap...>]

Heh :)

I will make your suggested changes to the Javadoc :)

Gavin

----- Original Message -----
From: "Anton van Straaten" <an...@ap...>
To: "Gavin King" <ga...@ap...>; "hibernate list"
<hib...@li...>
Sent: Monday, September 23, 2002 1:41 PM
Subject: RE: [Hibernate] iterator docs


> No defense needed, I was just attempting a teensy bit of newbieproofing.
:)
>
> I think the docs in sec. 6.3 are absolutely fine, but I was thinking of
the
> case where someone reads the Javadoc and doesn't manage to locate the
> relevant section of the reference docs.  This came up because I was going
to
> quote the docs on the forum in reply to that last message, and I found
that
> the Javadoc wasn't suitable for that purpose.
>
> Then you beat me to a response again, so I turned my email into a doc
update
> suggestion... :)
>
> Anton

RE: [Hibernate] iterator docs

[Anton v. S. <an...@ap...>]

No defense needed, I was just attempting a teensy bit of newbieproofing. :)

I think the docs in sec. 6.3 are absolutely fine, but I was thinking of the
case where someone reads the Javadoc and doesn't manage to locate the
relevant section of the reference docs.  This came up because I was going to
quote the docs on the forum in reply to that last message, and I found that
the Javadoc wasn't suitable for that purpose.

Then you beat me to a response again, so I turned my email into a doc update
suggestion... :)

Anton

Re: [Hibernate] iterator docs

[Gavin K. <ga...@ap...>]

Yeah, I guess we should improve that part of the documentation. However, in
my defence, the documentation includes the following passage. I think "The
iterator will load objects on demand" is fairly suggestive......


Quote:
=====
If you expect your query to return a very large number of objects, but you
don't expect to use them all, you will get better performance from the
iterate() methods, which return a java.util.Iterator. The iterator will load
objects on demand.

Iterator iter = sess.iterate("from q in class eg.Qux");
while ( iter.hasNext() ) {
    Qux qux = (Qux) iter.next();
    // something we couldnt express in the query
    if ( qux.calculateComplicatedAlgorithm() ) {
        // delete the current instance
        iter.remove();
        // dont need to process the rest
        break;
    }
}
Unfortunately java.util.Iterator does not declare any exceptions, so any SQL
or Hibernate exceptions that occur are wrapped in a
LazyInitializationException (a subclass of RuntimeException).

The iterate() method also performs better if you expect that many of the
objects are already loaded and cached by the session. For small result sets
where no data is already cached, find() is a better choice.



----- Original Message -----
From: "Anton van Straaten" <an...@ap...>
To: "hibernate list" <hib...@li...>
Sent: Monday, September 23, 2002 1:06 PM
Subject: [Hibernate] iterator docs


> Gavin,
>
> Not that this will necessarily forestall all newbie questions about it,
but
> I think the Javadoc for iterator() could be more explicit.  It currently
> says:
>
> "Execute a query and return the results in an iterator. Results are lazily
> instantiated. Write the given value to "?" in the query string.  iterate()
> is usually a less efficient way to retrieve objects than find()."
>
> A user might be forgiven for assuming that "lazily instantiated" means
that
> objects are instantiated lazily, when requested, from a single resultset
for
> the entire query.  The docs in "6.3 Querying the database" explain this
> better.  Perhaps the last sentence above could be replaced with something
> like this:
>
> "The iterator returned by iterate() will issue a separate database query
for
> each object that is requested, except for objects that are already loaded
> and cached in the session.  In many situations, it is more efficient to
use
> find()."
>
> Adjust to reflect reality... :)
>
> Anton
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

[Hibernate] iterator docs

[Anton v. S. <an...@ap...>]

Gavin,

Not that this will necessarily forestall all newbie questions about it, but
I think the Javadoc for iterator() could be more explicit.  It currently
says:

"Execute a query and return the results in an iterator. Results are lazily
instantiated. Write the given value to "?" in the query string.  iterate()
is usually a less efficient way to retrieve objects than find()."

A user might be forgiven for assuming that "lazily instantiated" means that
objects are instantiated lazily, when requested, from a single resultset for
the entire query.  The docs in "6.3 Querying the database" explain this
better.  Perhaps the last sentence above could be replaced with something
like this:

"The iterator returned by iterate() will issue a separate database query for
each object that is requested, except for objects that are already loaded
and cached in the session.  In many situations, it is more efficient to use
find()."

Adjust to reflect reality... :)

Anton

Re[2]: [Hibernate] Whats the correct NUMERIC type for *your* database?

[Doug C. <e...@fl...>]

> Do you know if you need to specify a precision and/or scale value for
> NUMERIC columns in McKoi ... ie. is there some dumb default value like
> scale=0?

Nope. Mckoi stores NUMERIC as BigDecimal any way you declare it. An
unadorned NUMERIC is just fine.

e

Re: [Hibernate] Whats the correct NUMERIC type for *your* database?

[Gavin K. <ga...@ap...>]

Cool! Thanks, Doug...

Do you know if you need to specify a precision and/or scale value for
NUMERIC columns in McKoi ... ie. is there some dumb default value like
scale=0?

----- Original Message -----
From: "Doug Currie" <e...@fl...>
To: "Gavin King" <ga...@ap...>
Sent: Monday, September 23, 2002 11:57 AM
Subject: Re: [Hibernate] Whats the correct NUMERIC type for *your* database?


> Gavin,
>
> I put an update to FooBarTest.java into CVS -- it removes restrictions
> on MckoiDialect. I have FooBarTested Hibernate with Mckoi 0.94e.
>
> I added these lines to MckoiDialect.java and placed in CVS:
>
>         public String getSequenceNextValString(String sequenceName) {
>                 return  "SELECT UNIQUEKEY('" + sequenceName + "')";
>         }
>         public String getCreateSequenceString(String sequenceName) {
>                 return "CREATE TABLE " + sequenceName + "(id NUMERIC)";
>         }
>         public String getDropSequenceString(String sequenceName) {
>                return "DROP TABLE " + sequenceName;
>         }
>
> Re: your query... I believe Mckoi treats both column types NUMERIC and
> DECIMAL equivalently as BigDecimals.
>
> Regards,
>
> e
>
> Sunday, September 22, 2002, 8:34:44 PM, you wrote:
>
> > Hi everyone,
>
> > in response to a user request, I'm adding a BigDecimal type. According
to
> > the JDBC spec, the correct mapping for this type is Types.NUMERIC. So we
> > need to go ahead and add a NUMERIC type to all the dialects. To make
this a
> > bit easier, would people please let me know what database column type
> > Types.NUMERIC should be mapped to for their platforms?

Re: [Hibernate] Whats the correct NUMERIC type for *your* database?

[Christian M. <vc...@cl...>]

Postgresql  column type for types.NUMERIC is numeric
--> 
http://developer.postgresql.org/docs/postgres/datatype.html#DATATYPE-NUMERIC

Regards
Chris

Gavin King wrote:

>Hi everyone,
>
>in response to a user request, I'm adding a BigDecimal type. According to
>the JDBC spec, the correct mapping for this type is Types.NUMERIC. So we
>need to go ahead and add a NUMERIC type to all the dialects. To make this a
>bit easier, would people please let me know what database column type
>Types.NUMERIC should be mapped to for their platforms?
>
>TIA
>
>Gavin
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>hibernate-devel mailing list
>hib...@li...
>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>  
>

[Hibernate] Whats the correct NUMERIC type for *your* database?

[Gavin K. <ga...@ap...>]

Hi everyone,

in response to a user request, I'm adding a BigDecimal type. According to
the JDBC spec, the correct mapping for this type is Types.NUMERIC. So we
need to go ahead and add a NUMERIC type to all the dialects. To make this a
bit easier, would people please let me know what database column type
Types.NUMERIC should be mapped to for their platforms?

TIA

Gavin

[Hibernate] 1.1 final is up

[Gavin K. <ga...@ap...>]

Enjoy!

Re: [Hibernate] JCS cache - Distributable read-write

[Christian M. <vc...@cl...>]

>
> > --> The session hold a set of the items that have been updated/deleted
in
> the transaction,
> > when the transaction commit, we iterate the set and remove each entry
from
> the cache.
>
> but merely removing is not enough, because after removal, another
> transaction (that started *earlier*) could come along and try to write
stale
> data in the cache because the database is actually free to return stale
data
> to a read operation. Thats the reason for the more complicated logic in
> read-write cache. What you have to ensure is that a transaction that
writes
> to the cache _started after the completion_ of the transaction that
removed
> the object from the cache. (This is what the current read-write cache
does.)

Haaa all is clear now ;)
I am planning to use hibernate is a kinda very large CMS portal and i intend
to rely on the cache as much as i can ( a la Jive, using only iterator no
bulk loading to maximise the cache use) hence my interest and need to fully
understand how the cache is handled internally.

I am a bit scared by all the synchronized method, even the "read" one is
synchronized....
Are we absolutly sure we need to synchronize the read method ? the
CachedItem contains pretty simple value that basically have 2 states ( the
timestamp is either -1 or a value (set/unset), the cached value is either
null or a value ( staled / fresh )). I tried to find an example where a
read/write conflict ( either the read thread is pre empted and the write
start or vis-versa) could lead to a bad cache state and i could not find
one.

> > With this logic, we end with a read only cache ( we never update an item
> in the cache) for
> > mutable objects.
>
> I don't understand how this is different to the existing read-write cache
> which actually doesn't allow *update* of a cached item, it only allows
> removal from the cache when an object is updated.

Ya you right, it's the same.

>
> There seems to be three types of cache:
>
> Type 1:
> you can add an item
> you can't remove an item
> you can't update an item
>
> Type 2:
> you can add an item
> you can remove an item (when you attempt to update it on the DB)
> you can't update an item
>
> Type 3:
> you can add an item
> you can update an item (when you *know* you have updated its persistent
> state)
>
> Hibernate supports Type 1 (read-only) and Type 2 (read-write) but not Type
> 3. Type 3 would require Hibernate to know whether or not a transaction is
> successful (which it doesn't, in general).

IMHO, Type 2 should really not be named "read-write" because we end
referencing it by a read-write cache where it's instead a read only cache
for read-write objects. A read-write cache is the type 3. For example,
pretty much every JDO implementation got a factory wide cache (type 2, same
purpose as the hibernate one) and they all call it "read only cache" because
the cache is read only, we never update an object in it.

>
> I'm not convinced that what you are implementing is different to Type 2
> (except that it seems to have some holes...)

You are right, once the holes are fixed, i end with the same thing as you.

Thanks for your help Gavin, i really appreciate.
Kind regards
Christian Meunier

Re: [Hibernate] JCS cache - Distributable read-write

[Gavin K. <ga...@ap...>]

> --> The session hold a set of the items that have been updated/deleted in
the transaction,
> when the transaction commit, we iterate the set and remove each entry from
the cache.

but merely removing is not enough, because after removal, another
transaction (that started *earlier*) could come along and try to write stale
data in the cache because the database is actually free to return stale data
to a read operation. Thats the reason for the more complicated logic in
read-write cache. What you have to ensure is that a transaction that writes
to the cache _started after the completion_ of the transaction that removed
the object from the cache. (This is what the current read-write cache does.)

> With this logic, we end with a read only cache ( we never update an item
in the cache) for
> mutable objects.

I don't understand how this is different to the existing read-write cache
which actually doesn't allow *update* of a cached item, it only allows
removal from the cache when an object is updated.

There seems to be three types of cache:

Type 1:
you can add an item
you can't remove an item
you can't update an item

Type 2:
you can add an item
you can remove an item (when you attempt to update it on the DB)
you can't update an item

Type 3:
you can add an item
you can update an item (when you *know* you have updated its persistent
state)

Hibernate supports Type 1 (read-only) and Type 2 (read-write) but not Type
3. Type 3 would require Hibernate to know whether or not a transaction is
successful (which it doesn't, in general).

I'm not convinced that what you are implementing is different to Type 2
(except that it seems to have some holes...)

Re: [Hibernate] collection indexing in query language

[Gavin K. <ga...@ap...>]

Ah ... I sort of got killed by line wrapping. I was trying to demonstrate
that an arithmetic and path expression could be nested inside a path
expression containing a []
----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: <hib...@li...>
Sent: Friday, September 20, 2002 6:57 PM
Subject: [Hibernate] collection indexing in query language


> I just finished implementing support for this kind of thing (in queries):
>
> from foo in class Foo where foo.bars[4].baz = 10
> from foo in class Foo where foo.map['baz'].name = 'foo'
> from foo in class Foo, fum in class Fum where fum = foo.bars[ (3 + 10) *
> 2 ].baz.fum
> from foo in class Foo, fum in class Fum where foo.bars[
> fum.fee.map['fi'].count ].baz = 12
>
> This is not especially well tested yet, so would people try it out and see
> how it goes please.....
>
> its in CVS
>
> I might sneak this into 1.1 or maybe leave it for 1.1.1
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] how to get the name of the matchtable

[Gavin K. <ga...@ap...>]

> In some situations it would also be fine if I could just get the name of
the
> match table with cat.match (just like cat.elements). I have a (legacy)
> database mapping here where the match tables contain all kinds of stuff (a
> sortpos, some date fields), that i could all use for order by, so it would
> be practical for me.

Hmmm this is something that never really occurred to me before. We have
proper support for match tables by using <composite-element> mappings (a
very powerful feature that I'm not sure people actually understand
properly). However queries can never refer to fields of composite elements!
Even with the new indexing [] stuff, I havn't (yet) implemented support for
composite elements.

[Hibernate] collection indexing in query language

[Gavin K. <ga...@ap...>]

I just finished implementing support for this kind of thing (in queries):

from foo in class Foo where foo.bars[4].baz = 10
from foo in class Foo where foo.map['baz'].name = 'foo'
from foo in class Foo, fum in class Fum where fum = foo.bars[ (3 + 10) *
2 ].baz.fum
from foo in class Foo, fum in class Fum where foo.bars[
fum.fee.map['fi'].count ].baz = 12

This is not especially well tested yet, so would people try it out and see
how it goes please.....

its in CVS

I might sneak this into 1.1 or maybe leave it for 1.1.1

Re: [Hibernate] how to get the name of the matchtable

[Christoph S. <ch...@mc...>]

Hi Gavin!

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: <hib...@li...>
Sent: Thursday, September 19, 2002 4:52 PM
Subject: Fw: [Hibernate] how to get the name of the matchtable


> Yeah, I have been trying to think of a ways to let you refer to the index
of
> a collection element from inside the query language but I havn't really
come
> up with anything. However, in this particular case, I'm not sure why you
are
> using a query at all. List elements are returned sorted by index already;
> simply load the List itself.... I'm assuming you have another where
> condition that you aren't displaying to us.
yeah, right :)
>
> Unfortunately the new collection filtering functionality doesn't help
> either, because its also not aware of collections indexes. What might be
> possible would be to allow a special "index" identifier in collection
> filters, the same way we allow "this" to refer to the element. That would
> solve your problem, wouldn't it?
yeah, that would be fine.
In some situations it would also be fine if I could just get the name of the
match table with cat.match (just like cat.elements). I have a (legacy)
database mapping here where the match tables contain all kinds of stuff (a
sortpos, some date fields), that i could all use for order by, so it would
be practical for me.

One other thing, actually in the case of my select its not necessary at all
to hit the cat table, the whole query could be resolved with just the
matchtable and Table1.

regards
 chris



>
>
> ----- Original Message -----
> From: Christoph Sturm
> To: hib...@li...
> Sent: Thursday, September 19, 2002 11:54 PM
> Subject: [Hibernate] how to get the name of the matchtable
>
>
> Hi All!
>
> I have 2 tables that have a n:m relation through a matchtable.
>
> table1 contains a definition like this:
>         <list role="categories" table="tema_x_vtrm" lazy="true">
>             <key column="vtrmid"/>
>             <index column="srtpos"/>
>             <many-to-many class="at.mcg.clubticket.db.Tema"
> column="temaid"/>
>         </list>
>
> and I'd like my elements to be sorted by srtpos.
>
> so I have to write
> select table from vtrm in class Table,  cat in table.categories.elements
> where cat.id = 2 order by cat0_.srtpos,
> because hibernate joins the matchtable as "cat0_". Now I dont like this,
> because its an implementation detail that could change.
>
> I often think that I dont understand all parts of the query language, so
> maybe there's an easy solution to this, and someone can enlighten me ;)
>
> regards
>  chris
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

[Hibernate] RE: Whats going on with XDoclet

[<seb...@sy...>]

No problem.  Go ahead!

-----Original Message-----
From: Gavin King [mailto:ga...@ap...]
Sent: September 19, 2002 7:38 AM
To: hibernate list
Cc: Sébastien Guimont
Subject: Whats going on with XDoclet


I have been in contact with the XDoclet team and they are very happy to take
ownership of the Hibernate XDoclet stuff. This should help make sure that
the Hibernate module keeps working as their APIs change. I'd just like to
check that thats okay with Sebastien....

Gavin

Re: [Hibernate] JCS cache - Distributable read-write

[Christian M. <vc...@cl...>]

Thanks Gavin for this !

At this stage of my brainstorming about the cache, if i had to code it, =
the logic would be this:

The Cache interface should be like yours but with a remove method also.

CachedItem would be simplified to :

{
    private long timestamp;
    private Object value
}

ClassPersister would hold a JCSCache instance


Load operation:

The method responsible for loading an object in the session would do the =
following ( very simplified view of the code, just the logic here)

if( cache.get(...) !=3D null) // the item is already in a cache and we =
get it from there
{
        if(CachedItem.getTimestamp() < session.getTimestamp() ) // has =
this cacheditem been put in the cache before the session has begun ?
        {
                //Use the cacheditem to assemble the object
        }
        else
        {
                LoadFromDb()  // load the item from the databaase
                                      // Notice that we do not then put =
the loaded item in the cache       =20
        }
}
else
{
        LoadFromDb()      // Load the item from the database
        cache.put(item)    // put the item in the cache
}

Update/Delete operation:

--> The session hold a set of the items that have been updated/deleted =
in the transaction, when the transaction commit, we iterate the set and =
remove each entry from the cache.

With this logic, we end with a read only cache ( we never update an item =
in the cache) for mutable objects.

Do you see an example where the transaction isolation would fail with =
this logic ?
Do you see why this would not work using a lateral caching in JCS ?

Regards
Christian Meunier

  ----- Original Message -----=20
  From: Gavin King=20
  Cc: hibernate list=20
  Sent: Thursday, September 19, 2002 1:34 PM
  Subject: Re: [Hibernate] JCS cache - Distributable read-write


  This is the email:

  =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1033840&forum_id=
=3D7517
    ----- Original Message -----=20
    From: Gavin King=20
    To: Christian Meunier=20
    Cc: hibernate list=20
    Sent: Thursday, September 19, 2002 9:25 PM
    Subject: Re: [Hibernate] JCS cache - Distributable read-write


    Nice diagram! I wish the Hibernate doco had some diagrams like =
that....

    What I mean by "transactional access" is we would have to be able to =
read a value out of the cache, check its timestamp, and then put a new =
value in the cache as an atomic operation. Currently we do this by =
synchronizing on the strategy object. That approach won't work for a =
distributed cache. I detailed an approach that would work (a remote =
LockServer) in a previous email. If you read that carefully you will see =
exactly how isolation would be broken without it.

[Hibernate] build 1.1rc3

[Gavin K. <ga...@ap...>]

Would people please do me a favor and try out 1.1rc3 as this is intended =
to be essentially the final version of 1.1 unless any new bugs are =
discovered.

TIA

Gavin

Fw: [Hibernate] how to get the name of the matchtable

[Gavin K. <ga...@ap...>]

Yeah, I have been trying to think of a ways to let you refer to the index of
a collection element from inside the query language but I havn't really come
up with anything. However, in this particular case, I'm not sure why you are
using a query at all. List elements are returned sorted by index already;
simply load the List itself.... I'm assuming you have another where
condition that you aren't displaying to us.

Unfortunately the new collection filtering functionality doesn't help
either, because its also not aware of collections indexes. What might be
possible would be to allow a special "index" identifier in collection
filters, the same way we allow "this" to refer to the element. That would
solve your problem, wouldn't it?


----- Original Message -----
From: Christoph Sturm
To: hib...@li...
Sent: Thursday, September 19, 2002 11:54 PM
Subject: [Hibernate] how to get the name of the matchtable


Hi All!

I have 2 tables that have a n:m relation through a matchtable.

table1 contains a definition like this:
        <list role="categories" table="tema_x_vtrm" lazy="true">
            <key column="vtrmid"/>
            <index column="srtpos"/>
            <many-to-many class="at.mcg.clubticket.db.Tema"
column="temaid"/>
        </list>

and I'd like my elements to be sorted by srtpos.

so I have to write
select table from vtrm in class Table,  cat in table.categories.elements
where cat.id = 2 order by cat0_.srtpos,
because hibernate joins the matchtable as "cat0_". Now I dont like this,
because its an implementation detail that could change.

I often think that I dont understand all parts of the query language, so
maybe there's an easy solution to this, and someone can enlighten me ;)

regards
 chris

[Hibernate] how to get the name of the matchtable

[Christoph S. <ch...@mc...>]

Hi All!

I have 2 tables that have a n:m relation through a matchtable.

table1 contains a definition like this:
        <list role=3D"categories" table=3D"tema_x_vtrm" lazy=3D"true">
            <key column=3D"vtrmid"/>
            <index column=3D"srtpos"/>
            <many-to-many class=3D"at.mcg.clubticket.db.Tema" =
column=3D"temaid"/>
        </list>

and I'd like my elements to be sorted by srtpos.

so I have to write
select table from vtrm in class Table,  cat in table.categories.elements =
where cat.id =3D 2 order by cat0_.srtpos,
because hibernate joins the matchtable as "cat0_". Now I dont like this, =
because its an implementation detail that could change.=20

I often think that I dont understand all parts of the query language, so =
maybe there's an easy solution to this, and someone can enlighten me ;)

regards
 chris

[Hibernate] Whats going on with XDoclet

[Gavin K. <ga...@ap...>]

I have been in contact with the XDoclet team and they are very happy to take
ownership of the Hibernate XDoclet stuff. This should help make sure that
the Hibernate module keeps working as their APIs change. I'd just like to
check that thats okay with Sebastien....

Gavin

Re: [Hibernate] JCS cache - Distributable read-write

[Gavin K. <ga...@ap...>]

This is the email:

http://sourceforge.net/mailarchive/forum.php?thread_id=3D1033840&forum_id=
=3D7517
  ----- Original Message -----=20
  From: Gavin King=20
  To: Christian Meunier=20
  Cc: hibernate list=20
  Sent: Thursday, September 19, 2002 9:25 PM
  Subject: Re: [Hibernate] JCS cache - Distributable read-write


  Nice diagram! I wish the Hibernate doco had some diagrams like =
that....

  What I mean by "transactional access" is we would have to be able to =
read a value out of the cache, check its timestamp, and then put a new =
value in the cache as an atomic operation. Currently we do this by =
synchronizing on the strategy object. That approach won't work for a =
distributed cache. I detailed an approach that would work (a remote =
LockServer) in a previous email. If you read that carefully you will see =
exactly how isolation would be broken without it.