hibernate-devel Mailing List for Hibernate (Page 328)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Gavin King wrote:

>P.S. I fixed the problem with update() and its in CVS....
>

Hmm...

Looks like that fixed my problem too.

Thanks,
-Mark

Gavin King wrote:

>Curious.
>
>I managed to reproduce an NPE just like this, but from update(), not
>save()......
>
>Are you sure it originated in save() .... can you show me a stack trace
>please.
>
Yes, I'm doing a save().  Stack trace:

java.lang.NullPointerException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at 
cirrus.hibernate.helpers.ReflectHelper.get(ReflectHelper.java:183)
        at 
cirrus.hibernate.type.ComponentType.getPropertyValue(ComponentType.java:161)
        at 
cirrus.hibernate.impl.SessionImpl.removeCollectionsFor(SessionImpl.java:846)
        at 
cirrus.hibernate.impl.SessionImpl.removeCollectionsFor(SessionImpl.java:808)
        at cirrus.hibernate.impl.SessionImpl.doUpdate(SessionImpl.java:952)
        at 
cirrus.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:897)
        at cirrus.hibernate.impl.Cascades$2.cascade(Cascades.java:37)
        at cirrus.hibernate.impl.Cascades.cascade(Cascades.java:130)
        at cirrus.hibernate.impl.SessionImpl.cascade(SessionImpl.java:1770)
        at cirrus.hibernate.impl.SessionImpl.doSave(SessionImpl.java:576)
        at cirrus.hibernate.impl.SessionImpl.save(SessionImpl.java:458)
        at misc.Test.test(Test.java:258)
        at misc.Test.main(Test.java:89)

Note that it says ReflectHelper.java:183 instead of 169 because I added 
a bunch of debug code to figure out what was null.

>I'm concerned that the testsuite didn't show this / these problems :(
>  
>
Yeah, that confused me too, since I checked the test suite and saw that 
there were tests for this, and thought it was something I was doing....

-Mark

P.S. I fixed the problem with update() and its in CVS....

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Mark Woon" <mor...@SM...>; "Hibernate Mailing List"
<hib...@li...>
Sent: Wednesday, September 25, 2002 9:23 PM
Subject: Re: [Hibernate] Problem with <component> element

> Curious.
>
> I managed to reproduce an NPE just like this, but from update(), not
> save()......
>
> Are you sure it originated in save() .... can you show me a stack trace
> please.
>
> I'm concerned that the testsuite didn't show this / these problems :(
>
> ----- Original Message -----
> From: "Mark Woon" <mor...@SM...>
> To: "Hibernate Mailing List" <hib...@li...>
> Sent: Wednesday, September 25, 2002 5:03 PM
> Subject: [Hibernate] Problem with <component> element
>
>
> >
> > I'm getting this with both 1.1 and what's currently in CVS.  I'm getting
> > an NPE at
> > cirrus.hibernate.helpers.ReflectHelper.get(ReflectHelper.java:169)
> > because target is null.
> >
> > My mapping looks like this:
> >
> >   <class name="Foo" table="Foos">
> >     <id name="id" column="id" type="string" unsaved-value="null">
> >       <generator class="assigned" />
> >     </id>
> >     <property name="name" />
> >     <component name="subComp" class="SubComp">
> >       <property name="version" column=version" />
> >       <property name="value" column="value" />
> >     </component>
> >   </class>
> >
> >
> > All I'm doing is:
> >
> > Foo f = new Foo();
> > f.setId("ID1");
> > session.save(f);
> >
> >
> > If I comment out the <component> element, everything works.
> >
> > Any ideas?
> >
> > -Mark
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
> -------------------------------------------------------
> 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

Curious.

I managed to reproduce an NPE just like this, but from update(), not
save()......

Are you sure it originated in save() .... can you show me a stack trace
please.

I'm concerned that the testsuite didn't show this / these problems :(

----- Original Message -----
From: "Mark Woon" <mor...@SM...>
To: "Hibernate Mailing List" <hib...@li...>
Sent: Wednesday, September 25, 2002 5:03 PM
Subject: [Hibernate] Problem with <component> element

>
> I'm getting this with both 1.1 and what's currently in CVS.  I'm getting
> an NPE at
> cirrus.hibernate.helpers.ReflectHelper.get(ReflectHelper.java:169)
> because target is null.
>
> My mapping looks like this:
>
>   <class name="Foo" table="Foos">
>     <id name="id" column="id" type="string" unsaved-value="null">
>       <generator class="assigned" />
>     </id>
>     <property name="name" />
>     <component name="subComp" class="SubComp">
>       <property name="version" column=version" />
>       <property name="value" column="value" />
>     </component>
>   </class>
>
>
> All I'm doing is:
>
> Foo f = new Foo();
> f.setId("ID1");
> session.save(f);
>
>
> If I comment out the <component> element, everything works.
>
> Any ideas?
>
> -Mark
>
>
>
> -------------------------------------------------------
> 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

I'm getting this with both 1.1 and what's currently in CVS.  I'm getting 
an NPE at 
cirrus.hibernate.helpers.ReflectHelper.get(ReflectHelper.java:169) 
because target is null.  

My mapping looks like this:

  <class name="Foo" table="Foos">
    <id name="id" column="id" type="string" unsaved-value="null">
      <generator class="assigned" />
    </id>
    <property name="name" />
    <component name="subComp" class="SubComp">
      <property name="version" column=version" />
      <property name="value" column="value" />
    </component>
  </class>

All I'm doing is:

Foo f = new Foo();
f.setId("ID1");
session.save(f);

If I comment out the <component> element, everything works.

Any ideas?

-Mark

I would appreciate if people would look over and try to understand the new
design.I would like to get as much input into this stuff as possible. My
goal was to cleanly seperate logic that is general to Hibernate's model of
entities/components/values/collections from code that implements a
particular strategy for persisting an entity. The most pressing need for
this was to support different mapping strategies like the normalized
table-per-subclass mapping. However, there are other (hypothetical) examples
of how "persistence strategies" might be useful:

  * an entity is persisted by stored procedure calls
  * an entity is persisted to LDAP
  * an entity persists instance variables with no property accessors

Now I don't propose that Hibernate would have built-in with persistence
strategies to address these cases (I view them as out-of-scope). However, it
would be nice to have an API we could point to and say: if you need to do
something different, implement this interface.

So I've added two new packages.

* the cirrus.hibernate.persister package defines
    - the contract between the session and persistence strategies
(ClassPersister)
    - the contract between QueryTranslator and a persistence strategy that
supports querying (Queryable)
    - the contract between Loader and a persistence strategy that supports
built-in loading
    - a default persistence strategy (EntityPersister)

* the cirrus.hibernate.loader package defines the built-in loading
mechanisms, which may or may not be used by a particular persistence
strategy
    - Loader implements the most generic logic used by all built-in loaders
and the QueryTranslator
    - OuterJoinLoader implements logic for loading a graph of associated
objects using outerjoins
    - etc.

As part of all that, I moved a lot of code around (and rewrote some bad
code) and cleaned up a number of internal interfaces.

SessionImpl is now completely abstracted from generated SQL and almost
completely abstracted from JDBC. Then only remaining code dealing with JDBC
is the code that does batching (which I dont know where else to put).

Critiques are very welcome :)

Gavin

Brad, if you need to fix errors, just fix them in the DocBook src and let me
know so I can recompile. It *is* a bit involved setting up the stuff you
need to compile the doco. You need the docbook DTD for a start. And we have
some slightly customized stylesheets (done by Christian) that I can send to
you, if you like. We will have to keep the XSL in CVS eventually but I'm
kinda waiting for Christian to finish whatever he needs to do with that
stuff....

I kinda prefer keeping the compiled doco in CVS because it means I can build
on a machine where I don't necessarily have Perl + AFT + Saxon + docbookx +
stylesheets all installed in the right places.

----- Original Message -----
From: Brad Clow
To: hib...@li...
Sent: Tuesday, September 24, 2002 8:56 PM
Subject: [Hibernate] documentation

there have been a couple of occasions recently where i have found some minor
errors in the documentation and would have liked to fix them up - but the
whole documentation thing looks a bit complex when u want to do a simple
change.

is it easy to generate the documentation - there is a docbook ant task that
seems to require saxon, but which version / is that all?  perhaps a note
somewhere in the distribution on how to generate the documentation and
required dependencies might be useful.  if this needs some work, i can help
out here.

also, is it possible to remove the generated documentation from cvs?

thanx

brad

No problem... I'll update from CVS tommorow, and try patching that =
version.

If I run into any problems, I'll let you know.

Jon...
  ----- Original Message -----=20
  From: Gavin King=20
  To: hibernate list=20
  Sent: Tuesday, September 24, 2002 5:31 PM
  Subject: Fw: [Hibernate] Oracle Style Joins Implemented

  Oh. Damn. Ummmm .... I have made *very* big changes to exactly that =
part of the code....

  Sorry, I don't know....

  You'll have to look over the code to see how it impacts. You might be =
lucky though, I imagine the changes will be much simpler now.

  Gavin
    ----- Original Message -----=20
    From: Jon Lipsky=20
    To: hib...@li...=20
    Sent: Tuesday, September 24, 2002 11:06 PM
    Subject: [Hibernate] Oracle Style Joins Implemented

    Hi,

    I've implemented outer join support for Oracle 8.  (Oracle 9 =
supports the ANSI style outer joins.)

    I know Gavin is working on some refactoring right now, so I wanted =
to make sure my work doesn't interfere with his before I check the =
patches in.  In order to implement this, I had to modify the following =
files (along with what I did):

    Environment.java - Added a "useOracleJoins" environment parameter

    Loader.java - Added helper methods to generate the additions to the =
from and the where clause for the Joins

    CollectionLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    EntityLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    OneToManyLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    Gavin, if this sounds alright to you, and doesn't conflict with your =
refactoring, then I will check this in.

    Thanks,
    Jon...

Oh. Damn. Ummmm .... I have made *very* big changes to exactly that part =
of the code....

Sorry, I don't know....

You'll have to look over the code to see how it impacts. You might be =
lucky though, I imagine the changes will be much simpler now.

Gavin
  ----- Original Message -----=20
  From: Jon Lipsky=20
  To: hib...@li...=20
  Sent: Tuesday, September 24, 2002 11:06 PM
  Subject: [Hibernate] Oracle Style Joins Implemented

  Hi,

  I've implemented outer join support for Oracle 8.  (Oracle 9 supports =
the ANSI style outer joins.)

  I know Gavin is working on some refactoring right now, so I wanted to =
make sure my work doesn't interfere with his before I check the patches =
in.  In order to implement this, I had to modify the following files =
(along with what I did):

  Environment.java - Added a "useOracleJoins" environment parameter

  Loader.java - Added helper methods to generate the additions to the =
from and the where clause for the Joins

  CollectionLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

  EntityLoader.java - Added check for join type, and then generate ANSI =
joins or Oracle joins.

  OneToManyLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

  Gavin, if this sounds alright to you, and doesn't conflict with your =
refactoring, then I will check this in.

  Thanks,
  Jon...

Yep, Dialects can now specify some default properties (which may be =
overridden). That should help.

Secondly, I approve of moving *some* SQL generation to the Dialect =
subclasses. I have been moving in that direction.
  ----- Original Message -----=20
  From: Jon Lipsky=20
  To: Christoph Sturm ; hib...@li...=20
  Sent: Tuesday, September 24, 2002 11:41 PM
  Subject: Re: [Hibernate] Oracle Style Joins Implemented

  Hi Chris,

  Yes, that was my initial thought however I thought it would complicate =
things even more to move the join implementation into the Dialects.  The =
first thing is that we would need two Oracle dialects, one for Oracle 8, =
and one for Oracle 9 since Oracle 9 *CAN* use ANSI style outer joins.  =
The other thing is that the SQL statements are genererated a little =
differently between the two join styles.  That would then move some of =
the SQL generation into the dialects, so I decided to leave it in the =
Loader classes.

  Perhaps Gavin has a better idea than using the Environment =
variable.?.? =20

  Jon...
    ----- Original Message -----=20
    From: Christoph Sturm=20
    To: Jon Lipsky ; hib...@li...=20
    Sent: Tuesday, September 24, 2002 3:20 PM
    Subject: Re: [Hibernate] Oracle Style Joins Implemented

    Hey Jon!

    Oracle Outer Joins are great, I have been needing this for quite =
some time :)

    But wouldnt it be better to let the database Dialect decide what =
kind of outer joins is generated instead of introducing a new parameter?

    regards
     chris

      ----- Original Message -----=20
      From: Jon Lipsky=20
      To: hib...@li...=20
      Sent: Tuesday, September 24, 2002 3:06 PM
      Subject: [Hibernate] Oracle Style Joins Implemented

      Hi,

      I've implemented outer join support for Oracle 8.  (Oracle 9 =
supports the ANSI style outer joins.)

      I know Gavin is working on some refactoring right now, so I wanted =
to make sure my work doesn't interfere with his before I check the =
patches in.  In order to implement this, I had to modify the following =
files (along with what I did):

      Environment.java - Added a "useOracleJoins" environment parameter

      Loader.java - Added helper methods to generate the additions to =
the from and the where clause for the Joins

      CollectionLoader.java - Added check for join type, and then =
generate ANSI joins or Oracle joins.

      EntityLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

      OneToManyLoader.java - Added check for join type, and then =
generate ANSI joins or Oracle joins.

      Gavin, if this sounds alright to you, and doesn't conflict with =
your refactoring, then I will check this in.

      Thanks,
      Jon...

Hi Chris,

Yes, that was my initial thought however I thought it would complicate =
things even more to move the join implementation into the Dialects.  The =
first thing is that we would need two Oracle dialects, one for Oracle 8, =
and one for Oracle 9 since Oracle 9 *CAN* use ANSI style outer joins.  =
The other thing is that the SQL statements are genererated a little =
differently between the two join styles.  That would then move some of =
the SQL generation into the dialects, so I decided to leave it in the =
Loader classes.

Perhaps Gavin has a better idea than using the Environment variable.?.?  =

Jon...
  ----- Original Message -----=20
  From: Christoph Sturm=20
  To: Jon Lipsky ; hib...@li...=20
  Sent: Tuesday, September 24, 2002 3:20 PM
  Subject: Re: [Hibernate] Oracle Style Joins Implemented

  Hey Jon!

  Oracle Outer Joins are great, I have been needing this for quite some =
time :)

  But wouldnt it be better to let the database Dialect decide what kind =
of outer joins is generated instead of introducing a new parameter?

  regards
   chris

    ----- Original Message -----=20
    From: Jon Lipsky=20
    To: hib...@li...=20
    Sent: Tuesday, September 24, 2002 3:06 PM
    Subject: [Hibernate] Oracle Style Joins Implemented

    Hi,

    I've implemented outer join support for Oracle 8.  (Oracle 9 =
supports the ANSI style outer joins.)

    I know Gavin is working on some refactoring right now, so I wanted =
to make sure my work doesn't interfere with his before I check the =
patches in.  In order to implement this, I had to modify the following =
files (along with what I did):

    Environment.java - Added a "useOracleJoins" environment parameter

    Loader.java - Added helper methods to generate the additions to the =
from and the where clause for the Joins

    CollectionLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    EntityLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    OneToManyLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

    Gavin, if this sounds alright to you, and doesn't conflict with your =
refactoring, then I will check this in.

    Thanks,
    Jon...

Hey Jon!

Oracle Outer Joins are great, I have been needing this for quite some =
time :)

But wouldnt it be better to let the database Dialect decide what kind of =
outer joins is generated instead of introducing a new parameter?

regards
 chris

  ----- Original Message -----=20
  From: Jon Lipsky=20
  To: hib...@li...=20
  Sent: Tuesday, September 24, 2002 3:06 PM
  Subject: [Hibernate] Oracle Style Joins Implemented

  Hi,

  I've implemented outer join support for Oracle 8.  (Oracle 9 supports =
the ANSI style outer joins.)

  I know Gavin is working on some refactoring right now, so I wanted to =
make sure my work doesn't interfere with his before I check the patches =
in.  In order to implement this, I had to modify the following files =
(along with what I did):

  Environment.java - Added a "useOracleJoins" environment parameter

  Loader.java - Added helper methods to generate the additions to the =
from and the where clause for the Joins

  CollectionLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

  EntityLoader.java - Added check for join type, and then generate ANSI =
joins or Oracle joins.

  OneToManyLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

  Gavin, if this sounds alright to you, and doesn't conflict with your =
refactoring, then I will check this in.

  Thanks,
  Jon...

Hi,

I've implemented outer join support for Oracle 8.  (Oracle 9 supports =
the ANSI style outer joins.)

I know Gavin is working on some refactoring right now, so I wanted to =
make sure my work doesn't interfere with his before I check the patches =
in.  In order to implement this, I had to modify the following files =
(along with what I did):

Environment.java - Added a "useOracleJoins" environment parameter

Loader.java - Added helper methods to generate the additions to the from =
and the where clause for the Joins

CollectionLoader.java - Added check for join type, and then generate =
ANSI joins or Oracle joins.

EntityLoader.java - Added check for join type, and then generate ANSI =
joins or Oracle joins.

OneToManyLoader.java - Added check for join type, and then generate ANSI =
joins or Oracle joins.

Gavin, if this sounds alright to you, and doesn't conflict with your =
refactoring, then I will check this in.

Thanks,
Jon...

there have been a couple of occasions recently where i have found some =
minor errors in the documentation and would have liked to fix them up - =
but the whole documentation thing looks a bit complex when u want to do =
a simple change.

is it easy to generate the documentation - there is a docbook ant task =
that seems to require saxon, but which version / is that all?  perhaps a =
note somewhere in the distribution on how to generate the documentation =
and required dependencies might be useful.  if this needs some work, i =
can help out here.

also, is it possible to remove the generated documentation from cvs?

thanx

brad

we currently use an application-level cache in our cms application that
operates like this:

1.  if i am getting a "transient" (r/o) object - go look in the cache, if
not there, load/find it with hibernate and place it in the cache.
2. if i want a "persistent" object (i want to modify it) - load/find it with
hibernate, modify, commit and then remove the object from the cache.

i am expecting that this will work in a clustered environment as long as all
the caches r notified to remove an object (if they have a copy) when it is
modified.

to add something like this to hibernate would require API changes that
enable the application to specify whether a persistent or transient instance
is required from a load/find.  i have a vague recollection that anton may
have brought this "r/o load/find" concept up before - is there a
(performance) benefit to be gained from this (with or w/o this caching
idea)?

brad

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Christian Meunier" <vc...@cl...>
Cc: "hibernate list" <hib...@li...>
Sent: Saturday, September 21, 2002 1:12 AM
Subject: Re: [Hibernate] JCS cache - Distributable read-write

>
> > --> 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...)
>
>
>
> -------------------------------------------------------
> 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
>

Was wondering if someone have looked to Middlegen ?
--> http://boss.bekk.no/boss/middlegen/

Might be usefull to code an hibernate plugin...

Here you go
--> http://www.tangosol.com/products-clustering-overview.jsp

Found a nice diagram that we could hack a bit to explain centralized =
lockserver
--> http://www.fastobjects.com/images/FO_ActiveCaching.gif=20
  From: Gavin King=20
  To: Christian Meunier=20
  Cc: hibernate list=20
  Sent: Tuesday, September 24, 2002 10:14 AM
  Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

  Do you have a reference (URL) for this?

  sorry ... I still havn't looked at your other emails......refactoring =
continues....
Woops! forgot to remove some files. Thats fixed now.

Now, regarding your proposed patch, I just ran this test:
public class TEst {

public static void main(String[] args) {

System.out.println(new HashMap().values().iterator().hasNext());

System.out.println(new THashMap().values().iterator().hasNext());

System.out.println(new TreeMap().values().iterator().hasNext());

}

}

Which gave the results I expected. (Namely printed false three times, no
exception.) Exactly which implementation of Map are you using that returns
null from values()? I would put that result down to an incorrect
implementation of the Map interface.....

----- Original Message -----
From: "Mark Woon" <mor...@SM...>
To: "Hibernate Mailing List" <hib...@li...>
Sent: Tuesday, September 24, 2002 4:57 PM
Subject: [Hibernate] NPE in cirrus.hibernate.collections.Map

> Gavin,
>
> You've been busy!  Unfortunately, CVS is is not compilable at the
> moment.  Lots of errors about ambiguous references due to multiple
> classes with the same name.
>
> I'm also getting an NPE in cirrus.hibernate.collections.Map @ line 180
> when the collection is empty.  A patch to fix this is attached.
>
> -Mark
>

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

> ? build
> ? patch.diff
> ? lib/j2ee.jar
> ? lib/junit.jar
> Index: cirrus/hibernate/collections/Map.java
> ===================================================================
> RCS file:
/cvsroot/hibernate/Hibernate/cirrus/hibernate/collections/Map.java,v
> retrieving revision 1.42
> diff -b -c -r1.42 Map.java
> *** cirrus/hibernate/collections/Map.java 11 Sep 2002 12:07:27 -0000 1.42
> --- cirrus/hibernate/collections/Map.java 24 Sep 2002 06:54:09 -0000
> ***************
> *** 9,14 ****
> --- 9,15 ----
>   import java.util.Collection;
>   import java.util.HashSet;
>   import java.util.Iterator;
> + import java.util.ListIterator;
>
>   import org.odmg.DMap;
>
> ***************
> *** 176,183 ****
> --- 177,188 ----
>   * @see PersistentCollection#elements()
>   */
>   public Iterator elements() {
> +           Collection col = map.values();
> +           if (col != null) {
>               return map.values().iterator();
>             }
> +           return new ListIterator();
> + }
>   public boolean empty() {
>   return map.isEmpty();
>   }
>

Do you have a reference (URL) for this?

sorry ... I still havn't looked at your other emails......refactoring =
continues....
  ----- Original Message -----=20
  From: Christian Meunier=20
  To: hib...@li...=20
  Sent: Tuesday, September 24, 2002 4:14 PM
  Subject: Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

  I found a pretty good description of the 2 read-write strategy that =
ideally hibernate should support ( the current one and the one i named =
"lightweight read-write" but the good name is optimistic-read-write

  a.. The Synchronized Replicated Cache  ensures the coordinated =
synchronization of data across the entire cluster with the guaranteed =
minimum amount of network traffic and support for automatic fail-over. =
Provide thread-safe access and concurrency support for coordinated =
locking on a network. (what we got with centralized lock server)

  a.. The Optimistic Replicated Cache sacrifices the =
cluster-synchronized concurrency control mechanism found in the =
Synchronized Replicated Cache in order to provide the theoretical =
maximum possible throughput of any clustered replicated cache =
implementation. (what i would like to see supported too)

  Regards, Chris.

    From: Christian Meunier=20
    To: hib...@li...=20
    Sent: Tuesday, September 24, 2002 5:53 AM
    Subject: [Hibernate] RE: DistributedCacheConcurrencyStrategy

    Little more input on the subject:

    I thought how to achieve maximum flexibility and keep a clean code =
for the cache, i came up with the following design that makes more sense =
IMHO than using a DistributedCacheConcurrency:

    (1) Define a lockserver interface
    (2) Implement a local lockserver
    (3) Implement a centralized lockserver
    (4) Optionally implement a distributed lockserver  ( the one i =
actually did but i believe centralized one makes more sense)

    (5) Refactor the ReadWriteCacheConcurrency:
       =20
         (a) Remove Synchonized methods
         (b) use the lockserver interface

    (6) Refactor the <jcs-cache> tag so we can:

        (a) Specify a strategy to use ( either "read-only" or =
"read-write" or a full class name "com.foo.MyCacheConcurrencyStrategy" )
        (b) Optionally specify a lockserver to use ( either "local" or =
"centralized" or a full class name "com.foo.MyLockServer" )
       =20
    (7) Add a remove method to the Cache interface so we allow =
implementation such the proposed "lightweight readwrite" ( see my =
previous email) to use it. Clearly state in the javadoc tag that using =
this method an implementation can not fully ensure tx isolation in all =
case.

    At the end we should end with a pretty strong and plugable cache in =
Hibernate ;)

    Another topic:

    What is the correct behaviour regarding the lockserver, i believe i =
did something wrong in the distributable prototype, i mean when we try =
to acquire a lock and the server responds saying the object is already =
locked. Should we then go to the database ( what i currently do ) or =
wait and retry.
    I believe the latter is the correct answer.

    Best regards
    Christian Meunier    =20

Gavin,

You've been busy!  Unfortunately, CVS is is not compilable at the 
moment.  Lots of errors about ambiguous references due to multiple 
classes with the same name.

I'm also getting an NPE in cirrus.hibernate.collections.Map @ line 180 
when the collection is empty.  A patch to fix this is attached.

-Mark

I found a pretty good description of the 2 read-write strategy that =
ideally hibernate should support ( the current one and the one i named =
"lightweight read-write" but the good name is optimistic-read-write

a.. The Synchronized Replicated Cache  ensures the coordinated =
synchronization of data across the entire cluster with the guaranteed =
minimum amount of network traffic and support for automatic fail-over. =
Provide thread-safe access and concurrency support for coordinated =
locking on a network. (what we got with centralized lock server)

a.. The Optimistic Replicated Cache sacrifices the cluster-synchronized =
concurrency control mechanism found in the Synchronized Replicated Cache =
in order to provide the theoretical maximum possible throughput of any =
clustered replicated cache implementation. (what i would like to see =
supported too)

Regards, Chris.

  From: Christian Meunier=20
  To: hib...@li...=20
  Sent: Tuesday, September 24, 2002 5:53 AM
  Subject: [Hibernate] RE: DistributedCacheConcurrencyStrategy

  Little more input on the subject:

  I thought how to achieve maximum flexibility and keep a clean code for =
the cache, i came up with the following design that makes more sense =
IMHO than using a DistributedCacheConcurrency:

  (1) Define a lockserver interface
  (2) Implement a local lockserver
  (3) Implement a centralized lockserver
  (4) Optionally implement a distributed lockserver  ( the one i =
actually did but i believe centralized one makes more sense)

  (5) Refactor the ReadWriteCacheConcurrency:
     =20
       (a) Remove Synchonized methods
       (b) use the lockserver interface

  (6) Refactor the <jcs-cache> tag so we can:

      (a) Specify a strategy to use ( either "read-only" or "read-write" =
or a full class name "com.foo.MyCacheConcurrencyStrategy" )
      (b) Optionally specify a lockserver to use ( either "local" or =
"centralized" or a full class name "com.foo.MyLockServer" )
     =20
  (7) Add a remove method to the Cache interface so we allow =
implementation such the proposed "lightweight readwrite" ( see my =
previous email) to use it. Clearly state in the javadoc tag that using =
this method an implementation can not fully ensure tx isolation in all =
case.

  At the end we should end with a pretty strong and plugable cache in =
Hibernate ;)

  Another topic:

  What is the correct behaviour regarding the lockserver, i believe i =
did something wrong in the distributable prototype, i mean when we try =
to acquire a lock and the server responds saying the object is already =
locked. Should we then go to the database ( what i currently do ) or =
wait and retry.
  I believe the latter is the correct answer.

  Best regards
  Christian Meunier    =20

Little more input on the subject:

I thought how to achieve maximum flexibility and keep a clean code for =
the cache, i came up with the following design that makes more sense =
IMHO than using a DistributedCacheConcurrency:

(1) Define a lockserver interface
(2) Implement a local lockserver
(3) Implement a centralized lockserver
(4) Optionally implement a distributed lockserver  ( the one i actually =
did but i believe centralized one makes more sense)

(5) Refactor the ReadWriteCacheConcurrency:
   =20
     (a) Remove Synchonized methods
     (b) use the lockserver interface

(6) Refactor the <jcs-cache> tag so we can:

    (a) Specify a strategy to use ( either "read-only" or "read-write" =
or a full class name "com.foo.MyCacheConcurrencyStrategy" )
    (b) Optionally specify a lockserver to use ( either "local" or =
"centralized" or a full class name "com.foo.MyLockServer" )
   =20
(7) Add a remove method to the Cache interface so we allow =
implementation such the proposed "lightweight readwrite" ( see my =
previous email) to use it. Clearly state in the javadoc tag that using =
this method an implementation can not fully ensure tx isolation in all =
case.

At the end we should end with a pretty strong and plugable cache in =
Hibernate ;)

Another topic:

What is the correct behaviour regarding the lockserver, i believe i did =
something wrong in the distributable prototype, i mean when we try to =
acquire a lock and the server responds saying the object is already =
locked. Should we then go to the database ( what i currently do ) or =
wait and retry.
I believe the latter is the correct answer.

Best regards
Christian Meunier    =20

Fixed :)

----- Original Message -----
From: "Fay, Kevin J, ALBAS" <kev...@at...>
To: <hib...@li...>
Sent: Tuesday, September 24, 2002 6:44 AM
Subject: [Hibernate] Hibernate documentation

> I'm attempting to download the Hibernate reference documentation .pdf file
and it says "The file is damaged and couldn't be repaired". The URL is.....
>
> http://hibernate.sourceforge.net/reference/pdf/hibernate_reference.pdf
>
> If you could fix this that would be great as I am quickly moving to
integrate Hibernate into our application.
>
> Thanks,
> Kevin Fay
>
>
> -------------------------------------------------------
> 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

I'm attempting to download the Hibernate reference documentation .pdf =
file and it says "The file is damaged and couldn't be repaired". The URL =
is.....

http://hibernate.sourceforge.net/reference/pdf/hibernate_reference.pdf

If you could fix this that would be great as I am quickly moving to =
integrate Hibernate into our application.

Thanks,
Kevin Fay

Hehe no worry, i just hope you use Intellij IDEA ;)
Happy refactoring.

Chris

Gavin King wrote:

>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 !
>
>  
>

2002	Jan (2)	Feb (157)	Mar (111)	Apr (61)	May (68)	Jun (45)	Jul (101)	Aug (132)	Sep (148)	Oct (227)	Nov (141)	Dec (285)
2003	Jan (518)	Feb (462)	Mar (390)	Apr (488)	May (321)	Jun (336)	Jul (268)	Aug (374)	Sep (211)	Oct (246)	Nov (239)	Dec (173)
2004	Jan (110)	Feb (131)	Mar (85)	Apr (120)	May (82)	Jun (101)	Jul (54)	Aug (65)	Sep (94)	Oct (51)	Nov (56)	Dec (168)
2005	Jan (146)	Feb (98)	Mar (75)	Apr (118)	May (85)	Jun (75)	Jul (44)	Aug (94)	Sep (70)	Oct (84)	Nov (115)	Dec (52)
2006	Jan (113)	Feb (83)	Mar (217)	Apr (158)	May (219)	Jun (218)	Jul (189)	Aug (39)	Sep (3)	Oct (7)	Nov (4)	Dec (2)
2007	Jan	Feb (2)	Mar (7)	Apr (3)	May (3)	Jun (8)	Jul (1)	Aug (1)	Sep	Oct (4)	Nov (7)	Dec
2008	Jan (1)	Feb (1)	Mar	Apr	May	Jun	Jul (2)	Aug (4)	Sep	Oct (2)	Nov (1)	Dec
2009	Jan (6)	Feb	Mar (1)	Apr (2)	May (1)	Jun (1)	Jul (10)	Aug	Sep (1)	Oct (1)	Nov	Dec (3)
2010	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep (2)	Oct	Nov	Dec
2012	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec

hibernate-devel Mailing List for Hibernate (Page 328)

An object relational-mapping (ORM) library for Java

hibernate-devel — development