Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-10-20 07:52:02
|
Q29saW4sIFRyZXZvciwNCiANClNlc3Npb24uc2F2ZSBpbW1lZGlhdGVseSBpbnNlcnRzIHRoZSBv YmplY3QgdG8gdGhlIGRhdGFiYXNlLCB0aGVyZWZvcmUgaXQgaXMgYWJsZSB0byBzZXQgaWQgaW50 byB0aGUgb2JqZWN0IGluIGFueSBjYXNlLiBBRkFJSywgU2Vzc2lvbi51cGRhdGUganVzdCBpbnNl cnRzIHRoZSBvYmplY3QgaW50byB0aGUgU2Vzc2lvbidzIG9iamVjdCBjYWNoZSwgdG8gYmUgZmx1 c2hlZCBpbiB0aGUgbm9ybWFsIHdheS4gU28gU2Vzc2lvbi5zYXZlIHNlZW1zIHRvIHJlY2VpdmUg c3BlY2lhbCB0cmVhdG1lbnQuDQogDQo+PmF1dG8taW5jcmVtZW50IGp1c3QgYWxsb3dzIHRvIHJl YWQgaW4gdGhlIGFjdHVhbCBpZCBhZnRlcndhcmRzDQo+VGhpcyBpcyBub3QgcmVsaWFibGUgZm9y IGNvbmN1cnJlbnQgaW5zZXJ0cyAod2hpY2ggaXMgd2h5IEkgZ2VuZXJhbGx5IHVzZSBzZXF1ZW5j ZXMuICBGb3IgdGhlIHNhbXBsZSB0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50IHRob3VnaC4NCiAN ClRoaXMgaXMgbm90IHJlbGlhYmxlIGV2ZW4gd2l0aCBwcm9wZXIgdHJhbnNhY3Rpb25zPyBTaG91 bGRuJ3QgImxhc3RfaW5zZXJ0X2lkIiBvciB3aGF0ZXZlciBpdCBpcyBjYWxsZWQgcmV0dXJuIHRo ZSBsYXN0IGluc2VydGVkIGlkIGluIHRoZSBzYW1lIHRyYW5zYWN0aW9uLCBhbGxvd2luZyBmb3Ig Y29uY3VycmVudCBpbnNlcnRzIGluIGRpZmZlcmVudCB0cmFuc2FjdGlvbnM/DQogDQpCYXNpY2Fs bHksIHRoZSBjaGFuZ2UgZm9yIHRoZSBzYW1wbGUgd291bGQgYmUgc3RyYWlnaHRmb3J3YXJkOiBE cm9wIGFsbCB0aGUgbWFudWFsbHkgaGFuZGxlZCBzZXF1ZW5jZSB0YWJsZXMgYW5kIHR1cm4gdGhl IGlkIGNvbHVtbnMgaW50byBpZGVudGl0eSBjb2x1bW5zLiBUaGlzIHdvdWxkIGFsbG93IGZvciB1 c2luZyBIaWJlcm5hdGUncyBvdXQtb2YtdGhlLWJveCAiaWRlbnRpdHkiIHN0cmF0ZWd5OyB0aGUg SkRCQyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBoYXZlIHRvIGRvIG1hbnVhbCAibGFzdF9pbnNlcnRf aWQiIHF1ZXJpZXMgYWZ0ZXIgdGhlIGFjdHVhbCBkb21haW4gaW5zZXJ0cy4NCiANCkp1ZXJnZW4N CiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBDb2xpbiBT YW1wYWxlYW51IFttYWlsdG86Y29saW5tbDFAZXhpcy5jb21dIA0KCUdlc2VuZGV0OiBNbyAyMC4x MC4yMDAzIDA1OjI3IA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv cGVyXSBQZXRjbGluaWMgSGliZXJuYXRlIGltcGxlbWVudGF0aW9uDQoJDQoJDQoNCglqw7xyZ2Vu IGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KCQ0KCT5IaSBldmVyeWJvZHksDQoJPg0KCT4uLi4N Cgk+DQoJPkJUVywgd2UgYXJlIHVzaW5nIGF1dG8taW5jcmVtZW50IGZvciBhbGwgTXlTUUwgZGF0 YWJhc2VzIGF0IHdlcmszQVQsIGFuZCBpdCB3b3JrcyBuaWNlbHkuIEknZCByZWFsbHkgbGlrZSB0 byB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIG1hbnVhbCBzZXF1ZW5jZSBoYW5kbGluZy4g VGhlIG9ubHkgb25lIEkgc2VlIGlzIHRoYXQgdGhlIGlkIGNhbiBiZSBkZXRlcm1pbmVkIGJlZm9y ZSB0aGUgZG9tYWluIGluc2VydC91cGRhdGUgc3RhdGVtZW50IHRoaXMgd2F5LCB3aGlsZSBhdXRv LWluY3JlbWVudCBqdXN0IGFsbG93cyB0byByZWFkIGluIHRoZSBhY3R1YWwgaWQgYWZ0ZXJ3YXJk cy4gQnV0IGRvZXMgdGhhdCByZWFsbHkgbWF0dGVyIGZvciBQZXRjbGluaWM/IFdvdWxkbid0IGl0 IGJlIGVhc2llciB0byB1c2UgYXV0by1pbmNyZW1lbnQvaWRlbnRpdHkgb24gYm90aCBNeVNRTCBh bmQgSFNRTD8NCgk+DQoJPiANCgk+DQoJT25seSBzb21ld2hhdCByZWxhdGVkLCBidXQgaG93IGRv ZXMgdGhlIGF1dG8taW5jcmVtZW50IGdldCBoYW5kbGVkDQoJdy9yZWdhcmRzIHRvIEhpYmVybmF0 ZSdzICdzYXZlJyBmdW5jdGlvbj8gVGhhdCBpcywgd2l0aCBhbiBPcmFjbGUNCglzZXF1ZW5jZSBv ciBzb21lIG9mIHRoZSBvdGhlciAoaGkvbG8sIGV0Yy4pIHN0cmF0ZWdpZXMsIHdoZW4geW91IGNh bGwNCglIaWJlcm5hdGUncyBzYXZlIGZ1bmN0aW9uLCB5b3VyIG9iamVjdHMgd2lsbCBnZXQgcHJv cGVyIGlkcywgZXZlbiB0aG91Z2gNCgl0aGV5IGRvbid0IGdldCB3cml0dGVuIHRvIHRoZSBkYiB1 bnRpbCB0aGV5IGFjdHVhbGx5IGdldCBmbHVzaGVkLiBUaGlzDQoJaXMgYmVjYXVzZSB0aGUgZGIg aGFzIGFscmVhZHkgYmVlbiBoaXQgZm9yIHRoZSBPcmFjbGUgc2VxdWVuY2Ugb3IgZm9yDQoJdGhl IG1hbnVhbCBzZXF1ZW5jZSB0YWJsZSBjb2x1bW4uDQoJDQoJV2hhdCBoYXBwZW5zIGluIHlvdXIg Y2FzZSB3aXRoIE15U1FMJ3MgYXV0by1pbmNyZW1lbnQgY29sdW1ucw0KCShlc3NlbnRpYWxseSBz aW1pbGFyIHRvIFNRTCBTZXJ2ZXIncyBpZGVudGl0eSBjb2x1bW5zKS4gRG8gdGhlIElEcyBzdGF5 DQoJbnVsbCAob3Igd2hhdGV2ZXIgdGhlIHVuc2F2ZWQgdmFsdWUgaXMpIHVudGlsIEhpYmVybmF0 ZSdzIGZsdXNoIGFjdHVhbGx5DQoJZ2V0cyBjYWxsZWQ/DQoJIEp1c3QgY3VyaW91cyBzaW5jZSBJ J3ZlIG5ldmVyIHVzZWQgZWl0aGVyIE15U1FMIG9yIFNRTCBTZXJ2ZXIgd2l0aA0KCUhpYmVybmF0 ZS4uLg0KCQ0KCUNvbGluDQoJDQoJDQoJDQoJdGVsbCBIaWJlcm5hdGUgdG8NCgkNCglIb3cgZG8g eW91IHByb3Blcmx5IGhhbmRsZQ0KCQ0KCQ0KCT5UaGlzIGlzc3VlIGlzIHByZXR0eSB1cmdlbnQg YWN0dWFsbHksIGFzIEknZCBsaWtlIHRvIGdldCBNMiBvdXQgbWlkIG5leHQgd2VlazsgdGhhdCdz IGFscmVhZHkgc2xpZ2h0bHkgYmVoaW5kIHRoZSBvcmlnaW5hbCBzY2hlZHVsZSB3aXRoIGEgcmVs ZWFzZSB0aGlzIHdlZWtlbmQuIEkgYmVsaWV2ZSB0aGF0IGEgd29ya2luZyBTcHJpbmcvSGliZXJu YXRlIHNhbXBsZSAodGhlIG51bWJlciBvbmUgcXVlc3Rpb24gb24gdGhlIEhpYmVybmF0ZSBmb3J1 bXMpIGlzIHdvcnRoIGEgc2xpZ2h0IGRlbGF5LCB0aG91Z2guDQoJPg0KCT5KdWVyZ2VuDQoJPg0K CT5QLlMuOg0KCT5KZWFuLVBpZXJyZSwgd2hhdCdzIHRoZSBzdGF0dXMgb2YgeW91ciBMaWdodC1D b3VudHJpZXMgc2FtcGxlPyBEbyB3ZSByZWFsbHkgbmVlZCBpdD8gQ291bnRyaWVzIGNvbmZpZ3Vy ZWQgdG8gdGhlIG1lbW9yeSBEQU8gc2hvdWxkIGJlIG5pY2UgZW5vdWdoLi4uIEkgZG8gbm90IGlu dGVuZCB0byBpbmNsdWRlIGl0IGluIGRpc3RyaWJ1dGlvbnMsIGZvciB0aGUgdGltZSBiZWluZy4N Cgk+DQoJPlAuUC5TLjogVG8gbWFrZSB0aGUgSGliZXJuYXRlIGltcGwgb2YgUGV0Y2xpbmljIHdv cmsgb3V0LW9mLXRoZS1ib3gsIHdlIG5lZWQgdG8gc2hpcCB0aGUgbWFpbiBsaWJyYXJpZXMgb2Yg SGliZXJuYXRlIDIuMC4zIHdpdGggU3ByaW5nLiBUaGF0J3MgMS42IGFkZGl0aW9uYWwgTUJzLCB3 aXRob3V0IHRoZSBKQ1MgY2FjaGUuIERvZXMgYW55b25lIG9iamVjdCB0byB0aGF0Pw0KCT4NCgk+ UC5QLlAuUy46DQoJPldoeSBpcyAiTXlTUUxNYXhWYWx1ZUluY3JlbWVudGVyIiB3cml0dGVuIHdp dGggdXBwZXItY2FzZSAiU1FMIiBidXQgIkhzcWxNYXhWYWx1ZUluY3JlbWVudGVyIiBub3Q/IElz IGl0IGp1c3QgYmVjYXVzZSBDVlMgZG9lc24ndCBzdXBwb3J0IGNhc2UgcmVuYW1pbmc/IDstKQ0K CT4NCgk+Thg/SFnetemailspP3soPz9bP0k/ej9rP8eLP3s/Fj8/Kid9P96dx4TGmhM/Py96e0U/ Pz8/Q2rWnHp7Xj8qJT/YqD/ErT8/Xj8nPz90P3hJP3o/az/Hiz97Pz97YXgaGj8/P2g/Pxc/Pz8/ OT8/ceinthc/ej/erRooPxttPz8/Pwc/Pz8/Kx4/KT8/Pys/Zyg/Kms/eB8/Pz/Cij91P96WP14/ Zj8/KT8rLUo/Pwc/amc/Pz8dej8/PystPz8uP8efPz8ePz9hPz9sPz9iPz8sPz8/eT8rPz/etz9i Pz8/PystP3c/Pz9rP3gfPz8/woo/dT/elj9ecj09PQ0KCT4NCgkNCgkNCgkNCgkNCgkNCgktLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhp cyBTRi5uZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBFbnRlcnByaXNlIExpbnV4IEZvcnVtIENvbmZl cmVuY2UgJiBFeHBvDQoJVGhlIEV2ZW50IEZvciBMaW51eCBEYXRhY2VudGVyIFNvbHV0aW9ucyAm IFN0cmF0ZWdpZXMgaW4gVGhlIEVudGVycHJpc2UNCglMaW51eCBpbiB0aGUgQm9hcmRyb29tOyBp biB0aGUgRnJvbnQgT2ZmaWNlOyAmIGluIHRoZSBTZXJ2ZXIgUm9vbQ0KCWh0dHA6Ly93d3cuZW50 ZXJwcmlzZWxpbnV4Zm9ydW0uY29tDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0K CVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6 Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRl dmVsb3Blcg0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-10-20 17:49:36
|
Thomas, Trevor, > Does Hibernate use a different ID strategy for different databases? I = think what is implemented in the Petclinic is a strategy that would work the = same across different databses as long as there is a MaxValueIncrementer = implementation. I intend to configure Hibernate to use "identity" for all databases. = Setting the correct Hibernate dialect will lead to "auto_increment" on = MySQL and "identity" on HSQL then. In terms of the data model, this = simply means dropping the sequence tables and defining the id columns as = "auto_increment" respectively "identity" in the DDL scripts. Sure, MaxValueIncrementer adopts a very generic approach that will work = on any database, even if it doesn't support such a thing like identity = columns. The disadvantage is that the mechanism is normally not native = to the database and thus somewhat tied to the application. > If we change the Petclinic JDBC implementation to use identity = columns, then we need to figure out how to run the insert and subsequent query to = retrieve the id using the same connection whether we are in a transaction or not. This is very similar with MySQL and HSQL: You simply run the insert = without specifying a value for the id field, and query "select = last_insert_id()" respectively "call identity()" afterwards (I've looked = up the latter in Hibernate's MySQLDialect and HSQLDialect = implementations). Petclinic already uses MySQLJdbcClinic and = HSQLJdbcClinic subclasses; it should be easy to encapsulate the = id-fetching query there. Of course, the range of possible Petclinic JDBC implementations will = then be bound to identity-supporting databases. According to the = Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and = HypersonicSQL". Oracle is notably absent; I think we can live with = Petclinic not running on Oracle, if we can allow for a dynamic switch = between JDBC and Hibernate on both MySQL and HSQL that way! >>auto-increment just allows to read in the actual id afterwards >This is not reliable for concurrent inserts (which is why I generally = use sequences. For the sample this should be sufficient though. According to what I found out about MySQL, "last_insert_id" returns the = last used id on the same connection and is thus transactionally safe. = Don't know about HSQL, but I frankly don't mind for sample purposes. Juergen |
|
From: <tri...@tr...> - 2003-10-20 18:52:15
|
Juergen, > According to what I found out about MySQL, "last_insert_id" returns the last > used id on the same connection and is thus transactionally safe. Don't know > about HSQL, but I frankly don't mind for sample purposes. > HSQL has IDENTITY() which returns the last identity value for the connection - so the functionality is basically the same. We just have to make sure that we use the same connection - an sqlUpdate followed by an sqlQuery might not gurantee this. I have been thinking about creating a datasource that makes the same conection available for a series of database interactions (with supressClose turned on) - like a temporary SingleConnectionDataSource created from a pooled DataSource. What do you think of a MultipleUseConnectionDataSource that gets a DataSource passed in the constructor. This MultipleUseConnectionDataSource could then be passed in to several sqlUpdate or sqlQuery objects and deflect any attempts to close it during this sequence of database interaction. Finally we would call destroy() on the MultipleUseConnectionDataSource causing the connection to be returned to the pool. Thomas |
|
From: Colin S. <col...@ex...> - 2003-10-20 20:02:24
|
jürgen höller [werk3AT] wrote: >Thomas, Trevor, > >>oes Hibernate use a different ID strategy for different databases? I think >> >> >what is implemented in the Petclinic is a strategy that would work the same >across different databses as long as there is a MaxValueIncrementer implementation. > >I intend to configure Hibernate to use "identity" for all databases. Setting the correct Hibernate dialect will lead to "auto_increment" on MySQL and "identity" on HSQL then. In terms of the data model, this simply means dropping the sequence tables and defining the id columns as "auto_increment" respectively "identity" in the DDL scripts. > >Sure, MaxValueIncrementer adopts a very generic approach that will work on any database, even if it doesn't support such a thing like identity columns. The disadvantage is that the mechanism is normally not native to the database and thus somewhat tied to the application. > >>f we change the Petclinic JDBC implementation to use identity columns, then we >> >> >need to figure out how to run the insert and subsequent query to retrieve the id >using the same connection whether we are in a transaction or not. > >This is very similar with MySQL and HSQL: You simply run the insert without specifying a value for the id field, and query "select last_insert_id()" respectively "call identity()" afterwards (I've looked up the latter in Hibernate's MySQLDialect and HSQLDialect implementations). Petclinic already uses MySQLJdbcClinic and HSQLJdbcClinic subclasses; it should be easy to encapsulate the id-fetching query there. > >Of course, the range of possible Petclinic JDBC implementations will then be bound to identity-supporting databases. According to the Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL". Oracle is notably absent; I think we can live with Petclinic not running on Oracle, if we can allow for a dynamic switch between JDBC and Hibernate on both MySQL and HSQL that way! > > I guess you are trying to make the exact same thing run under both Hibernate and JDBC, but if you are willing to say the Oracle DB only works with the Hibernate version (and handle the DDL separately too), then you can easily do that by just using 'native' as the Hibernate type... |
|
From: Ken K. <kk...@kk...> - 2003-10-20 22:03:18
|
It might be most useful to implement one of the 2 databases as is using=20 the MaxValueIncrementer while implementing the other using Hibernate to=20 preserve both types of examples. Ken j=FCrgen h=F6ller [werk3AT] wrote: >Thomas, Trevor, > > =20 > >>Does Hibernate use a different ID strategy for different databases? I = think >> =20 >> >what is implemented in the Petclinic is a strategy that would work the s= ame >across different databses as long as there is a MaxValueIncrementer impl= ementation. > >I intend to configure Hibernate to use "identity" for all databases. Set= ting the correct Hibernate dialect will lead to "auto_increment" on MySQL= and "identity" on HSQL then. In terms of the data model, this simply mea= ns dropping the sequence tables and defining the id columns as "auto_incr= ement" respectively "identity" in the DDL scripts. > >Sure, MaxValueIncrementer adopts a very generic approach that will work = on any database, even if it doesn't support such a thing like identity co= lumns. The disadvantage is that the mechanism is normally not native to t= he database and thus somewhat tied to the application. > > =20 > >>If we change the Petclinic JDBC implementation to use identity columns,= then we >> =20 >> >need to figure out how to run the insert and subsequent query to retriev= e the id >using the same connection whether we are in a transaction or not. > >This is very similar with MySQL and HSQL: You simply run the insert with= out specifying a value for the id field, and query "select last_insert_id= ()" respectively "call identity()" afterwards (I've looked up the latter = in Hibernate's MySQLDialect and HSQLDialect implementations). Petclinic a= lready uses MySQLJdbcClinic and HSQLJdbcClinic subclasses; it should be e= asy to encapsulate the id-fetching query there. > >Of course, the range of possible Petclinic JDBC implementations will the= n be bound to identity-supporting databases. According to the Hibernate d= ocs, those are "DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL". Ora= cle is notably absent; I think we can live with Petclinic not running on = Oracle, if we can allow for a dynamic switch between JDBC and Hibernate o= n both MySQL and HSQL that way! > > =20 > >>>auto-increment just allows to read in the actual id afterwards >>> =20 >>> >>This is not reliable for concurrent inserts (which is why I generally u= se sequences. For the sample this should be sufficient though. >> =20 >> > >According to what I found out about MySQL, "last_insert_id" returns the = last used id on the same connection and is thus transactionally safe. Don= 't know about HSQL, but I frankly don't mind for sample purposes. > >Juergen > > >------------------------------------------------------- >This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo >The Event For Linux Datacenter Solutions & Strategies in The Enterprise=20 >Linux in the Boardroom; in the Front Office; & in the Server Room=20 >http://www.enterpriselinuxforum.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > =20 > |
|
From: <jue...@we...> - 2003-10-20 22:28:16
|
VGhvbWFzLA0KIA0KV2UgZG9uJ3QgbmVlZCB0byBhZGRyZXNzIHRoYXQgYXQgdGhlIERhdGFTb3Vy Y2UgbGV2ZWwuIFdoeSBub3Qgc2ltcGx5IGV4ZWN1dGUgdGhlIHNlcmllcyBvZiBTUUwgb3BlcmF0 aW9ucyB3aXRoaW4gYSB0cmFuc2FjdGlvbj8gV2l0aCBEYXRhU291cmNlVHJhbnNhY3Rpb25NYW5h Z2VyIG9yIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciwgRGF0YVNvdXJjZVV0aWxzLmdldENv bm5lY3Rpb24gd2lsbCBhbHdheXMgcmV0dXJuIHRoZSBzYW1lIENvbm5lY3Rpb24gd2l0aGluIGEg dGhyZWFkLWJvdW5kIHRyYW5zYWN0aW9uLiBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgZGVwZW5kcyBv biB0aGUgSlRBIGltcGxlbWVudGF0aW9uOyBhbnkgcmVhc29uYWJsZSBvbmUgd2l0aCBsb2NhbCB0 cmFuc2FjdGlvbiBvcHRpbWl6YXRpb24gd2lsbCByZXR1cm4gdGhlIHNhbWUgQ29ubmVjdGlvbiB3 aXRoaW4gYSB0cmFuc2FjdGlvbiB0b28uDQogDQpJJ2xsIG1ha2UgUGV0Y2xpbmljJ3MgQ2xpbmlj IGJ1c2luZXNzIG9iamVjdCB0cmFuc2FjdGlvbmFsIGFueXdheSwgbWFpbmx5IGFzIHNob3djYXNl IGZvciBTcHJpbmcncyB0cmFuc2FjdGlvbiBpbmZyYXN0cnVjdHVyZS4gU28gZXhlY3V0aW5nIGlu c2VydHMgd2l0aGluIGEgdHJhbnNhY3Rpb24gd2lsbCBiZSBuYXR1cmFsLg0KIA0KSnVlcmdlbg0K IA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IHRyaXNiZXJn QHRyaWRiLmNvbSBbbWFpbHRvOnRyaXNiZXJnQHRyaWRiLmNvbV0gDQoJR2VzZW5kZXQ6IE1vIDIw LjEwLjIwMDMgMjA6MTcgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291 cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJdIFBldGNsaW5pYyBIaWJlcm5hdGUgaW1wbGVtZW50YXRpb24NCgkNCgkNCg0KCUp1ZXJn ZW4sDQoJDQoJPiBBY2NvcmRpbmcgdG8gd2hhdCBJIGZvdW5kIG91dCBhYm91dCBNeVNRTCwgImxh c3RfaW5zZXJ0X2lkIiByZXR1cm5zIHRoZSBsYXN0DQoJPiB1c2VkIGlkIG9uIHRoZSBzYW1lIGNv bm5lY3Rpb24gYW5kIGlzIHRodXMgdHJhbnNhY3Rpb25hbGx5IHNhZmUuIERvbid0IGtub3cNCgk+ IGFib3V0IEhTUUwsIGJ1dCBJIGZyYW5rbHkgZG9uJ3QgbWluZCBmb3Igc2FtcGxlIHB1cnBvc2Vz Lg0KCT4NCgkNCglIU1FMIGhhcyBJREVOVElUWSgpIHdoaWNoIHJldHVybnMgdGhlIGxhc3QgaWRl bnRpdHkgdmFsdWUgZm9yIHRoZSBjb25uZWN0aW9uIC0NCglzbyB0aGUgZnVuY3Rpb25hbGl0eSBp cyBiYXNpY2FsbHkgdGhlIHNhbWUuICBXZSBqdXN0IGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgd2UN Cgl1c2UgdGhlIHNhbWUgY29ubmVjdGlvbiAtIGFuIHNxbFVwZGF0ZSBmb2xsb3dlZCBieSBhbiBz cWxRdWVyeSBtaWdodCBub3QNCglndXJhbnRlZSB0aGlzLiAgSSBoYXZlIGJlZW4gdGhpbmtpbmcg YWJvdXQgY3JlYXRpbmcgYSBkYXRhc291cmNlIHRoYXQgbWFrZXMgdGhlDQoJc2FtZSBjb25lY3Rp b24gYXZhaWxhYmxlIGZvciBhIHNlcmllcyBvZiBkYXRhYmFzZSBpbnRlcmFjdGlvbnMgKHdpdGgN CglzdXByZXNzQ2xvc2UgdHVybmVkIG9uKSAtIGxpa2UgYSB0ZW1wb3JhcnkgU2luZ2xlQ29ubmVj dGlvbkRhdGFTb3VyY2UgY3JlYXRlZA0KCWZyb20gYSBwb29sZWQgRGF0YVNvdXJjZS4gDQoJDQoJ V2hhdCBkbyB5b3UgdGhpbmsgb2YgYSBNdWx0aXBsZVVzZUNvbm5lY3Rpb25EYXRhU291cmNlIHRo YXQgZ2V0cyBhIERhdGFTb3VyY2UNCglwYXNzZWQgaW4gdGhlIGNvbnN0cnVjdG9yLiAgVGhpcyBN dWx0aXBsZVVzZUNvbm5lY3Rpb25EYXRhU291cmNlIGNvdWxkIHRoZW4gYmUNCglwYXNzZWQgaW4g dG8gc2V2ZXJhbCBzcWxVcGRhdGUgb3Igc3FsUXVlcnkgb2JqZWN0cyBhbmQgZGVmbGVjdCBhbnkg YXR0ZW1wdHMgdG8NCgljbG9zZSBpdCBkdXJpbmcgdGhpcyBzZXF1ZW5jZSBvZiBkYXRhYmFzZSBp bnRlcmFjdGlvbi4gIEZpbmFsbHkgd2Ugd291bGQgY2FsbA0KCWRlc3Ryb3koKSBvbiB0aGUgTXVs dGlwbGVVc2VDb25uZWN0aW9uRGF0YVNvdXJjZSBjYXVzaW5nIHRoZSBjb25uZWN0aW9uIHRvIGJl DQoJcmV0dXJuZWQgdG8gdGhlIHBvb2wuDQoJDQoJVGhvbWFzDQoJDQoJDQoJDQoJLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0Yu bmV0IGVtYWlsIHNwb25zb3JlZCBieTogRW50ZXJwcmlzZSBMaW51eCBGb3J1bSBDb25mZXJlbmNl ICYgRXhwbw0KCVRoZSBFdmVudCBGb3IgTGludXggRGF0YWNlbnRlciBTb2x1dGlvbnMgJiBTdHJh dGVnaWVzIGluIFRoZSBFbnRlcnByaXNlDQoJTGludXggaW4gdGhlIEJvYXJkcm9vbTsgaW4gdGhl IEZyb250IE9mZmljZTsgJiBpbiB0aGUgU2VydmVyIFJvb20NCglodHRwOi8vd3d3LmVudGVycHJp c2VsaW51eGZvcnVtLmNvbQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXINCgkNCg0K |
|
From: <tri...@tr...> - 2003-10-21 02:47:33
|
Juergen, > We don't need to address that at the DataSource level. Why not simply execute > the series of SQL operations within a transaction? With > DataSourceTransactionManager or HibernateTransactionManager, > DataSourceUtils.getConnection will always return the same Connection within a > thread-bound transaction. JtaTransactionManager depends on the JTA > implementation; any reasonable one with local transaction optimization will > return the same Connection within a transaction too. > I was not just thinking about the Petclinic. I can see a general need for running a series of SQL statements or procedcure calls thet depend on running within the same connection - maybe there is some database state kept at the connection level or for some other reason. If we want to use the available Spring JDBC objects like SqlUpdate and SqlQuery for this, then this type of data source might come in handy. Thomas |
|
From: <jue...@we...> - 2003-10-21 02:01:00
|
SSBzZWUsIHRoZXJlJ3MgYSBsaW1pdGF0aW9uIGluIHRlcm1zIG9mIGlzb2xhdGlvbiBsZXZlbC4g QnV0IGFzIHlvdSBzYWlkLCB0aGF0J3Mgbm90IGFuIGlzc3VlIHdpdGggdGhlIHNhbXBsZSBhcHAg YXQgYWxsLiBBY3R1YWxseSwgSSdtIGp1c3QgcGxheWluZyB3aXRoIHRoZSBpZGVudGl0eS1iYXNl ZCB2ZXJzaW9uLCBhbmQgaXQgd29ya3MgbGlrZSBhIGNoYXJtISBTd2l0Y2hpbmcgYmV0d2VlbiBK REJDIGFuZCBIaWJlcm5hdGUgb24gSFNRTCBpcyBhIGJyZWV6ZTsgaXQncyBhIHBlcmZlY3Qgc2hv d2Nhc2UgZm9yIHRoZSBEQU8gcGF0dGVybiEgSSdtIGdvbm5hIHBvbGlzaCB0aGF0IHN0dWZmIGEg Yml0IGFuZCBtYWtlIGl0IHJlYWR5IGZvciBwcm9wZXIgZGVwbG95bWVudDsgaXQgc2hvdWxkIGJl IHJlYWR5IGZvciBjaGVja2luIHRvbW9ycm93Lg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFRyZXZvciBDb29rIFttYWlsdG86cHJp c2UwM0BzZW50ZXgubmV0XSANCglHZXNlbmRldDogTW8gMjAuMTAuMjAwMyAxOTozMCANCglBbjog c3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0K CUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gUGV0Y2xpbmljIEhpYmVy bmF0ZSBpbXBsZW1lbnRhdGlvbg0KCQ0KCQ0KDQoJPG1lPg0KCWF1dG8taW5jcmVtZW50IGp1c3Qg YWxsb3dzIHRvIHJlYWQgaW4gdGhlIGFjdHVhbCBpZCBhZnRlcndhcmRzDQoJVGhpcyBpcyBub3Qg cmVsaWFibGUgZm9yIGNvbmN1cnJlbnQgaW5zZXJ0cyAod2hpY2ggaXMgd2h5IEkgZ2VuZXJhbGx5 IHVzZSBzZXF1ZW5jZXMpDQoJPC9tZT4NCgkNCgk8anVlcmdlbj4NCglUaGlzIGlzIG5vdCByZWxp YWJsZSBldmVuIHdpdGggcHJvcGVyIHRyYW5zYWN0aW9ucz8gU2hvdWxkbid0ICJsYXN0X2luc2Vy dF9pZCIgb3Igd2hhdGV2ZXIgaXQgaXMgY2FsbGVkIHJldHVybiB0aGUgbGFzdCBpbnNlcnRlZCBp ZCBpbiB0aGUgc2FtZSB0cmFuc2FjdGlvbiwgYWxsb3dpbmcgZm9yIGNvbmN1cnJlbnQgaW5zZXJ0 cyBpbiBkaWZmZXJlbnQgdHJhbnNhY3Rpb25zPw0KCTwvanVlcmdlbj4NCgkNCglXaXRoIHRyYW5z YWN0aW9ucyBpdCBzaG91bGQgZnVuY3Rpb24gcHJvcGVybHkuICBUaGUgcHJvYmxlbSBpcyB0aGF0 IHdpdGggdHJhbnNhY3Rpb25zIHlvdSBoYXZlIGRpZmZlcmVudCBsb2NraW5nIHN0cmF0ZWdpZXMg d2hpY2ggaGF2ZSBkaWZmZXJlbnQgcGVyZm9ybWFuY2UgdHJhZGUtb2ZmcyBkZXBlbmRpbmcgb24g dGhlIGxldmVsIHVzZWQuICBJJ3ZlIGZvdW5kIHRoYXQgdXNpbmcgaWRlbnRpdHkgdHlwZSBmaWVs ZHMgbWFrZXMgdHJhbnNhY3Rpb25zIGFuZCBzcGVjaWZpYyBsb2NraW5nIHN0cmF0ZWdpZXMgcmVx dWlyZWQuICBCeSB1c2luZyBhIHNlcXVlbmNlLCBJIGNhbiBjaG9vc2UgZGlmZmVyZW50IHRyYW5z YWN0aW9uL2xvY2tpbmcgc3RyYXRlZ2llcyBkZXBlbmRpbmcgb24gcmVxdWlyZW1lbnRzL3BlcmZv cm1hbmNlICh1c2luZyB0aGUgaWRlbnRpdHkgc2VlbXMgdG8gbGltaXQgbXkgb3B0aW9ucykuDQoJ DQoJQWxzbywgaXQncyBnZW5lcmFsbHkgYSBsb3QgaGFyZGVyIHRvIGNoYW5nZSB0aGUgZGIgKGVz cGVjaWFsbHkgdGhlIHByaW1hcnkga2V5KSBhZnRlciBpdCdzIGluIHByb2R1Y3Rpb24uICBJIGNh biBkbyBhbnl0aGluZyBJIHdhbnQgd2l0aCBzZXF1ZW5jZXMsIGJ1dCBJIGhhdmUgbW9yZSBsaW1p dGVkIG9wdGlvbnMgd2l0aCBpZGVudGl0eS4gIElmIHRoZXkgd29yayB0b2RheSBidXQgbm90IHRv bW9ycm93LCBpdCdzIG5vIGxvbmdlciBhIHNpbXBsZSBjb2RlIGNoYW5nZSAoYW5kIGdldHRpbmcg YnVybmVkIGJ5IHRoaXMgYSBmZXcgdGltZXMgbWFkZSBtZSBjaGFuZ2UgdG8gc2VxdWVuY2VzIGFz IGEgZGVmYXVsdCkuICBUaGF0J3MganVzdCBteSBleHBlcmllbmNlL3ByZWZlcmVuY2UuICBBcyBJ IG1lbnRpb25lZCB0aG91Z2gsIGluIHRoaXMgY2FzZSBpdCBzaG91bGQgd29yayBjb3JyZWN0bHks IGFuZCBzaW5jZSBpdCdzIGEgc2FtcGxlIGFwcCBjaGFuZ2luZyB0aGUgZGIgbGF0ZXIgaXMgcGVy ZmVjdGx5IGFjY2VwdGFibGUuICBTb3JyeSBJIHRvb2sgdXMgYSBsaXR0bGUgb2ZmLXRvcGljLg0K CQ0KCVRyZXZvcg0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnkg T1NETiBkZXZlbG9wZXIgcmVsYXRpb25zDQoJSGVyZSdzIHlvdXIgY2hhbmNlIHRvIHNob3cgb2Zm IHlvdXIgZXh0ZW5zaXZlIHByb2R1Y3Qga25vd2xlZGdlDQoJV2Ugd2FudCB0byBrbm93IHdoYXQg eW91IGtub3cuIFRlbGwgdXMgYW5kIHlvdSBoYXZlIGEgY2hhbmNlIHRvIHdpbiAkMTAwDQoJaHR0 cDovL3d3dy56b29tZXJhbmcuY29tL3N1cnZleS56Z2k/SFJQVDFYM1JZUU5DNVY0TUxOU1YzRTU0 DQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5u ZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-10-21 17:13:53
|
Ken, everybody, I actually consider it as most effective to demonstrate portability = between both Hibernate/JDBC and HSQL/MySQL. IMO, it would just = complicate the implementation and thus make it harder to understand the = codebase if there were different id generation strategies within the = JDBC implementation, and switching to Hibernate just possible for one of = the two supported databases. I don't want to discredit the DataFieldMaxValueIncrementer support, it = definitely has value for strong portability requirements. It doesn't = match any Hibernate's way of id generation abstraction though, and I'd = like to make the code as easy as possible to understand for people that = already have a working knowledge of Hibernate. I've already committed the changes: All 4 combinations (Hibernate/HSQL, = Hibernate/MySQL, JDBC/HSQL, JDBC/MySQL) work nicely; the default is = Hibernate/HSQL now. When accessing the same database, the JDBC and = Hibernate implementations can work on exactly the same contents. = Furthermore, any data access is transactional now, via = TransactionProxyFactoryBean. Please give the stuff a review, if you like -- it's gonna get shipped = without much further refinement, as 1.0 M2 is about to be released this = week. Regards, Juergen P.S.: As a minor side note, I've removed the MySQL Connector 3.0 in the = lib-new directory as it is GPL; we're not allowed to distribute it = without becoming GPL ourselves. MySQL Connector 2.0.14 should be good = enough for the time being. -----Original Message----- From: Ken Krebs [mailto:kk...@kk...] Sent: Monday, October 20, 2003 11:41 PM To: spr...@li... Subject: [[W3-SPAM]] - Re: [Springframework-developer] Petclinic Hibernate implementation - Email found in subject It might be most useful to implement one of the 2 databases as is using=20 the MaxValueIncrementer while implementing the other using Hibernate to = preserve both types of examples. Ken j=FCrgen h=F6ller [werk3AT] wrote: >Thomas, Trevor, > > =20 > >>Does Hibernate use a different ID strategy for different databases? I = think >> =20 >> >what is implemented in the Petclinic is a strategy that would work the = same >across different databses as long as there is a MaxValueIncrementer = implementation. > >I intend to configure Hibernate to use "identity" for all databases. = Setting the correct Hibernate dialect will lead to "auto_increment" on = MySQL and "identity" on HSQL then. In terms of the data model, this = simply means dropping the sequence tables and defining the id columns as = "auto_increment" respectively "identity" in the DDL scripts. > >Sure, MaxValueIncrementer adopts a very generic approach that will work = on any database, even if it doesn't support such a thing like identity = columns. The disadvantage is that the mechanism is normally not native = to the database and thus somewhat tied to the application. > > =20 > >>If we change the Petclinic JDBC implementation to use identity = columns, then we >> =20 >> >need to figure out how to run the insert and subsequent query to = retrieve the id >using the same connection whether we are in a transaction or not. > >This is very similar with MySQL and HSQL: You simply run the insert = without specifying a value for the id field, and query "select = last_insert_id()" respectively "call identity()" afterwards (I've looked = up the latter in Hibernate's MySQLDialect and HSQLDialect = implementations). Petclinic already uses MySQLJdbcClinic and = HSQLJdbcClinic subclasses; it should be easy to encapsulate the = id-fetching query there. > >Of course, the range of possible Petclinic JDBC implementations will = then be bound to identity-supporting databases. According to the = Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and = HypersonicSQL". Oracle is notably absent; I think we can live with = Petclinic not running on Oracle, if we can allow for a dynamic switch = between JDBC and Hibernate on both MySQL and HSQL that way! > > =20 > >>>auto-increment just allows to read in the actual id afterwards >>> =20 >>> >>This is not reliable for concurrent inserts (which is why I generally = use sequences. For the sample this should be sufficient though. >> =20 >> > >According to what I found out about MySQL, "last_insert_id" returns the = last used id on the same connection and is thus transactionally safe. = Don't know about HSQL, but I frankly don't mind for sample purposes. > >Juergen > > >------------------------------------------------------- >This SF.net email sponsored by: Enterprise Linux Forum Conference & = Expo >The Event For Linux Datacenter Solutions & Strategies in The Enterprise = >Linux in the Boardroom; in the Front Office; & in the Server Room=20 >http://www.enterpriselinuxforum.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > =20 > ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2003-10-20 15:47:57
|
Interesting, so in the case of sequences (Oracle sequences, in any case), Hibernate's save (or saveOrUpdate) will go and read the next sequence value from the db, so it can assign the id, but will not actually write the row until the flush. In the case of identity columns, it does an actual write immediately (as per your comment below), which makes sense, as it's the only way it can actually get the id value to assign to the objects as part of the save or saveOrUpdate. This all has interesting implications in a few respects, including performance. Basically, I think user or Hibernate assigned IDs (such as GUIDs) would perform best, since the db is not hit until the actual entity write, followed by a seqhilo (hilo which uses a sequence for one half the value), followed by a hilo, then sequences, then identity. jürgen höller [werk3AT] wrote: >Colin, Trevor, > >Session.save immediately inserts the object to the database, therefore it is able to set id into the object in any case. AFAIK, Session.update just inserts the object into the Session's object cache, to be flushed in the normal way. So Session.save seems to receive special treatment. > > > >>>auto-increment just allows to read in the actual id afterwards >>> >>> >>This is not reliable for concurrent inserts (which is why I generally use sequences. For the sample this should be sufficient though. >> >> > >This is not reliable even with proper transactions? Shouldn't "last_insert_id" or whatever it is called return the last inserted id in the same transaction, allowing for concurrent inserts in different transactions? > >Basically, the change for the sample would be straightforward: Drop all the manually handled sequence tables and turn the id columns into identity columns. This would allow for using Hibernate's out-of-the-box "identity" strategy; the JDBC implementation would have to do manual "last_insert_id" queries after the actual domain inserts. > >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Colin Sampaleanu [mailto:col...@ex...] > Gesendet: Mo 20.10.2003 05:27 > An: spr...@li... > Cc: > Betreff: Re: [Springframework-developer] Petclinic Hibernate implementation > > > > jürgen höller [werk3AT] wrote: > > >Hi everybody, > > > >... > > > >BTW, we are using auto-increment for all MySQL databases at werk3AT, and it works nicely. I'd really like to understand the rationale for manual sequence handling. The only one I see is that the id can be determined before the domain insert/update statement this way, while auto-increment just allows to read in the actual id afterwards. But does that really matter for Petclinic? Wouldn't it be easier to use auto-increment/identity on both MySQL and HSQL? > > > > > > > Only somewhat related, but how does the auto-increment get handled > w/regards to Hibernate's 'save' function? That is, with an Oracle > sequence or some of the other (hi/lo, etc.) strategies, when you call > Hibernate's save function, your objects will get proper ids, even though > they don't get written to the db until they actually get flushed. This > is because the db has already been hit for the Oracle sequence or for > the manual sequence table column. > > What happens in your case with MySQL's auto-increment columns > (essentially similar to SQL Server's identity columns). Do the IDs stay > null (or whatever the unsaved value is) until Hibernate's flush actually > gets called? > Just curious since I've never used either MySQL or SQL Server with > Hibernate... > > Colin > > > |
|
From: Trevor C. <pr...@se...> - 2003-10-20 21:44:40
|
<me> auto-increment just allows to read in the actual id afterwards This is not reliable for concurrent inserts (which is why I generally = use sequences) </me> <juergen>=20 This is not reliable even with proper transactions? Shouldn't = "last_insert_id" or whatever it is called return the last inserted id in = the same transaction, allowing for concurrent inserts in different = transactions? </juergen> With transactions it should function properly. The problem is that with = transactions you have different locking strategies which have different = performance trade-offs depending on the level used. I've found that = using identity type fields makes transactions and specific locking = strategies required. By using a sequence, I can choose different = transaction/locking strategies depending on requirements/performance = (using the identity seems to limit my options). Also, it's generally a lot harder to change the db (especially the = primary key) after it's in production. I can do anything I want with = sequences, but I have more limited options with identity. If they work = today but not tomorrow, it's no longer a simple code change (and getting = burned by this a few times made me change to sequences as a default). = That's just my experience/preference. As I mentioned though, in this = case it should work correctly, and since it's a sample app changing the = db later is perfectly acceptable. Sorry I took us a little off-topic. Trevor |
