aboutsummaryrefslogtreecommitdiff
path: root/doc/TODO.detail/java
blob: 3a8420cfc4380cd3a03863b98e9abf34ceba77b8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
From pgsql-hackers-owner+M4145@postgresql.org Sat Feb  3 05:54:06 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id FAA22302
	for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 05:54:04 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13Ap4q95132;
	Sat, 3 Feb 2001 05:51:04 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4145@postgresql.org)
Received: from mail.retep.org.uk ([216.126.85.184])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13AnIq94863
	for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 05:49:18 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Received: from heather.retep.org.uk ([193.113.118.193])
	(authenticated)
	by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f13AlnO94823;
	Sat, 3 Feb 2001 05:47:49 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Message-Id: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
X-Sender: peter@mail.retep.org.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sat, 03 Feb 2001 10:46:24 +0000
To: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>
From: Peter Mount <peter@retep.org.uk>
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <Pine.BSO.4.10.10102021453160.9372-100000@spider.pilosoft.c
	om>
References: <20010202194049.38902.qmail@web12003.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

At 14:57 02/02/01 -0500, Alex Pilosov wrote:
>On Fri, 2 Feb 2001, tomasz konefal wrote:
>
> >   could someone please clarify what "Allow Java
> > server-side programming" actually means?  what are the
> > limitations of using java and jdbc with pgsql?
>
>It means to embed Java interpreter inside postgres, and allow writing
>stored procedures and triggers in Java.

Thats correct. Basically you are talking of something like PL/Java. The 
Java side would be simple, but its linking the JVM to the backend that's 
the problem.

It's been a while since I delved into the backend, but unless it's changed 
from fork() to threading, I don't really see this happening, unless someone 
who knows C that well knows of a portable way of communicating between two 
processes - other than RMI. If that could be solved, then you could use JNI 
to interface the JVM.

I know some people think this would slow the backend down, but it's only 
the instanciation of the JVM thats slow, hence the other reason fork() is 
holding this back. Ideally you would want the JVM to be running with 
PostMaster, and then each backend can then use the JVM as and when necessary.

Obviously you wouldn't want a JVM in every installation, but there are a 
lot of good reasons to have this capability. For example, as part of the 
course I did this week, we used Tomcat (Servlet/JSP/Web server). Now 
there's no reason why Tomcat could run within the same JVM. JBoss is 
another good example (EJB Server). The JBoss team have actually got Tomcat 
to run within the same JVM. Doesn't hinder performance at all, but does 
reduce the memory footprint.

This is a good future thing to look into (why not for 8.0 ;-) ). If we 
could find an _optional_ way of hooking the backend direct into the JVM, we 
could get PostgreSQL into a lot of new areas. It also would make things 
like CORBA etc a doddle.

PS: I'm writing down notes of the course to go onto the JDBC web site this 
weekend, so there's some nice things for EJB, RMI, Corba etc.

More later, Peter


From pgsql-hackers-owner+M4153@postgresql.org Sat Feb  3 11:54:12 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA13446
	for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 11:54:12 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13GrZq17345;
	Sat, 3 Feb 2001 11:53:35 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4153@postgresql.org)
Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13GnZq17000
	for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 11:49:37 -0500 (EST)
	(envelope-from peter_e@gmx.net)
Received: from fwd06.sul.t-online.com 
	by mailout04.sul.t-online.com with smtp 
	id 14P5rE-0000zq-00; Sat, 03 Feb 2001 17:48:16 +0100
Received: from peter.localdomain (520083510237-0001@[212.185.245.12]) by fmrl06.sul.t-online.com
	with esmtp id 14P5r6-0YvD60C; Sat, 3 Feb 2001 17:48:08 +0100
Date: Sat, 3 Feb 2001 17:56:33 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Peter Mount <peter@retep.org.uk>
cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
        <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
In-Reply-To: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
Message-ID: <Pine.LNX.4.30.0102031746220.8648-100000@peter.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sender: 520083510237-0001@t-dialin.net
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Peter Mount writes:

> Thats correct. Basically you are talking of something like PL/Java. The
> Java side would be simple, but its linking the JVM to the backend that's
> the problem.

I've tried that recently, here's how it looks as far as Linux JVMs go:

* Kaffe has a very polluted name space.  Calls to its own functions get
resolved to PostgreSQL, and vice versa.  Crash and burn result.  The Kaffe
folks have admitted that this should be fixed but I didn't look farther
yet.

* The Sun/Blackdown JVM didn't work at all (not even 'java -version')
until I upgraded my libc.  Then a simple test run crashes with an "error
external to JVM"; at first it looked like a segfault when referencing a
string constant.  In gdb I saw myself faced with about 10 threads running
when nothing was going on yet, at which point I was too exhausted to
proceed.

* IBM's offering didn't work at all.  I don't recall the problem anymore
but I think it didn't even link correctly.

So currently I don't see how this could become a mainstream project, let
alone across platforms.

> I know some people think this would slow the backend down, but it's only
> the instanciation of the JVM thats slow, hence the other reason fork() is
> holding this back. Ideally you would want the JVM to be running with
> PostMaster, and then each backend can then use the JVM as and when necessary.

But how do the other languages cope?  Starting up a new Perl for each
backend can't be so cheap either.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


From pgsql-hackers-owner+M4154@postgresql.org Sat Feb  3 12:37:02 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA00813
	for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 12:37:01 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13Haiq21225;
	Sat, 3 Feb 2001 12:36:44 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4154@postgresql.org)
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13HX9q20913
	for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 12:33:09 -0500 (EST)
	(envelope-from alex@pilosoft.com)
Received: from localhost (alexmail@localhost)
	by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id MAA09231;
	Sat, 3 Feb 2001 12:36:01 -0500 (EST)
Date: Sat, 3 Feb 2001 12:36:01 -0500 (EST)
From: Alex Pilosov <alex@pilosoft.com>
To: Peter Mount <peter@retep.org.uk>
cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
        pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
In-Reply-To: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
Message-ID: <Pine.BSO.4.10.10102031220470.10437-100000@spider.pilosoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

On Sat, 3 Feb 2001, Peter Mount wrote:

> It's been a while since I delved into the backend, but unless it's
> changed from fork() to threading, I don't really see this happening,
> unless someone who knows C that well knows of a portable way of
> communicating between two processes - other than RMI. If that could be
> solved, then you could use JNI to interface the JVM.
There are many ways one can do this:
a) each backend will have a JVM linked in (shared object). This is the
way perl/tcl/ruby is embedded, and it works pretty nice. But, Java
['s memory requirement] sucks, therefore, this may not be the optimal
way.

> I know some people think this would slow the backend down, but it's
> only the instanciation of the JVM thats slow, hence the other reason
> fork() is holding this back. Ideally you would want the JVM to be
> running with PostMaster, and then each backend can then use the JVM as
> and when necessary.
b) since JVM is threaded, it may be more efficient to have a dedicated
process running JVM, and accepting some sort of IPC connections from
postgres processes. The biggest problem here is SPI, there aren't a good
way for that JVM to talk back to database.

c) temporarily, to have quick working code, you can reach java using hacks
using programming languages already built into postgres. Both TCL (tcl
blend) and Perl (JPL and another hack which name escapes me) are able to
execute java code. SPI is possible, I think both of these bindings are
two-way (you can go perl-java-perl-java). Might be worth a quick try?
-alex
 


From pgsql-hackers-owner+M4164@postgresql.org Sun Feb  4 04:23:42 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id EAA04260
	for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 04:23:41 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f149Nhx75443;
	Sun, 4 Feb 2001 04:23:43 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4164@postgresql.org)
Received: from me.tm.ee (adsl895.estpak.ee [213.168.23.133])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f149Mgx75338
	for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 04:22:42 -0500 (EST)
	(envelope-from hannu@tm.ee)
Received: from tm.ee (IDENT:hannu@localhost.localdomain [127.0.0.1])
	by me.tm.ee (8.9.3/8.9.3) with ESMTP id LAA01488;
	Sun, 4 Feb 2001 11:18:09 +0200
Message-ID: <3A7D1E51.E383AB7F@tm.ee>
Date: Sun, 04 Feb 2001 11:18:09 +0200
From: Hannu Krosing <hannu@tm.ee>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Mount <peter@retep.org.uk>
CC: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
        pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
References: <20010202194049.38902.qmail@web12003.mail.yahoo.com> <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Peter Mount wrote:
> 
> At 14:57 02/02/01 -0500, Alex Pilosov wrote:
> >On Fri, 2 Feb 2001, tomasz konefal wrote:
> >
> > >   could someone please clarify what "Allow Java
> > > server-side programming" actually means?  what are the
> > > limitations of using java and jdbc with pgsql?
> >
> >It means to embed Java interpreter inside postgres, and allow writing
> >stored procedures and triggers in Java.
> 
> Thats correct. Basically you are talking of something like PL/Java. The
> Java side would be simple, but its linking the JVM to the backend that's
> the problem.
> 
> It's been a while since I delved into the backend, but unless it's changed
> from fork() to threading,

Someone posted here recently his port/tweaks of backend so that it used 
threads instead of fork(). IIRC it was done to be used inside a java 
client in an embedded system.

----------------
Hannu

From pgsql-hackers-owner+M4168@postgresql.org Sun Feb  4 06:54:27 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA19741
	for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 06:54:26 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f14BsOx83329;
	Sun, 4 Feb 2001 06:54:24 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4168@postgresql.org)
Received: from mail.retep.org.uk ([216.126.85.184])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f14Bs9x83240
	for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 06:54:09 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Received: from heather.retep.org.uk ([193.113.241.180])
	(authenticated)
	by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f14BqkR83161;
	Sun, 4 Feb 2001 06:52:46 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Message-Id: <5.0.2.1.0.20010204114942.00a0c8d0@mail.retep.org.uk>
X-Sender: peter@mail.retep.org.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 04 Feb 2001 11:51:21 +0000
To: Peter Eisentraut <peter_e@gmx.net>
From: Peter Mount <peter@retep.org.uk>
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
Cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
        <pgsql-hackers@postgresql.org>
In-Reply-To: <Pine.LNX.4.30.0102031746220.8648-100000@peter.localdomain>
References: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

At 17:56 03/02/01 +0100, Peter Eisentraut wrote:
>Peter Mount writes:
>
> > Thats correct. Basically you are talking of something like PL/Java. The
> > Java side would be simple, but its linking the JVM to the backend that's
> > the problem.
>
>I've tried that recently, here's how it looks as far as Linux JVMs go:

[snip]


>So currently I don't see how this could become a mainstream project, let
>alone across platforms.

I don't think it would be, but it would be a good side-project. Over time 
the various JVM's should become better to interface with.


> > I know some people think this would slow the backend down, but it's only
> > the instanciation of the JVM thats slow, hence the other reason fork() is
> > holding this back. Ideally you would want the JVM to be running with
> > PostMaster, and then each backend can then use the JVM as and when 
> necessary.
>
>But how do the other languages cope?  Starting up a new Perl for each
>backend can't be so cheap either.

But a lot cheaper than Java.

Peter


From pgsql-hackers-owner+M4169@postgresql.org Sun Feb  4 06:57:24 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA19817
	for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 06:57:23 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f14BvLx83711;
	Sun, 4 Feb 2001 06:57:21 -0500 (EST)
	(envelope-from pgsql-hackers-owner+M4169@postgresql.org)
Received: from mail.retep.org.uk ([216.126.85.184])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f14Bv7x83611
	for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 06:57:07 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Received: from heather.retep.org.uk ([193.113.241.180])
	(authenticated)
	by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f14BtjR83557;
	Sun, 4 Feb 2001 06:55:45 -0500 (EST)
	(envelope-from peter@retep.org.uk)
Message-Id: <5.0.2.1.0.20010204115139.009f1c50@mail.retep.org.uk>
X-Sender: peter@mail.retep.org.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 04 Feb 2001 11:54:20 +0000
To: Alex Pilosov <alex@pilosoft.com>
From: Peter Mount <peter@retep.org.uk>
Subject: Re: [HACKERS] TODO list:  Allow Java server-side programming
Cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
        pgsql-hackers@postgresql.org
In-Reply-To: <Pine.BSO.4.10.10102031220470.10437-100000@spider.pilosoft.
	com>
References: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

At 12:36 03/02/01 -0500, Alex Pilosov wrote:
>On Sat, 3 Feb 2001, Peter Mount wrote:

[snip]


> > I know some people think this would slow the backend down, but it's
> > only the instanciation of the JVM thats slow, hence the other reason
> > fork() is holding this back. Ideally you would want the JVM to be
> > running with PostMaster, and then each backend can then use the JVM as
> > and when necessary.
>b) since JVM is threaded, it may be more efficient to have a dedicated
>process running JVM, and accepting some sort of IPC connections from
>postgres processes. The biggest problem here is SPI, there aren't a good
>way for that JVM to talk back to database.

That was my other idea, but it is the IPC thats problematical. You would 
still need to do some native api to implement some messaging system between 
the two.

However, at the other extreme there is RPC, which is possible now, but 
would be a lot slower.


>c) temporarily, to have quick working code, you can reach java using hacks
>using programming languages already built into postgres. Both TCL (tcl
>blend) and Perl (JPL and another hack which name escapes me) are able to
>execute java code. SPI is possible, I think both of these bindings are
>two-way (you can go perl-java-perl-java). Might be worth a quick try?

Might be one way to go...

Peter

>-alex
>


From pgsql-jdbc-owner+M884@postgresql.org Wed Jun 27 13:36:09 2001
Return-path: <pgsql-jdbc-owner+M884@postgresql.org>
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f5RHa9q05483
	for <pgman@candle.pha.pa.us>; Wed, 27 Jun 2001 13:36:09 -0400 (EDT)
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
	by postgresql.org (8.11.3/8.11.1) with SMTP id f5RHaAa03078
	for <pgman@candle.pha.pa.us>; Wed, 27 Jun 2001 13:36:10 -0400 (EDT)
	(envelope-from pgsql-jdbc-owner+M884@postgresql.org)
Received: from net2.micro-automation.com (net2.micro-automation.com [64.7.141.29])
	by postgresql.org (8.11.3/8.11.1) with SMTP id f5RHOka96908
	for <pgsql-jdbc@postgresql.org>; Wed, 27 Jun 2001 13:24:46 -0400 (EDT)
	(envelope-from Dave@micro-automation.net)
Received: (qmail 32671 invoked from network); 27 Jun 2001 17:24:39 -0000
Received: from eboxwest.ebox.com (HELO INSPIRON) (206.51.23.194)
  by net2.micro-automation.com with SMTP; 27 Jun 2001 17:24:39 -0000
Reply-To: <Dave@micro-automation.net>
From: "Dave Cramer" <Dave@micro-automation.net>
To: "'Barry Lind'" <barry@xythos.com>
cc: <pgsql-jdbc@postgresql.org>
Subject: [JDBC] RE: Todo/missing? (was Re: [ADMIN] High memory usage [PATCH])
Date: Wed, 27 Jun 2001 13:22:42 -0400
Organization: Micro Automation Inc.
Message-ID: <008301c0ff2d$c885d880$0201a8c0@INSPIRON>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
In-Reply-To: <3B39352E.6060904@xythos.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Barry,

The getXXXFunctions aren't implemented
Some of the other functions are correct for version 7.1 but not for
previous versions. Ie. The row length, etc. I think the driver should
get the version and determine what is correct for each version. 

I think this is incorrect. 
  public boolean supportsSelectForUpdate() throws SQLException
  {
    // XXX-Not Implemented
    return false;
  }

There are a number of things here which are hard coded, and possible
wrong.

I started to work on this, but since I am going on vacation next week I
have a number of fires to get down to a slow burn before I go.

Dave

-----Original Message-----
From: Barry Lind [mailto:barry@xythos.com] 
Sent: June 26, 2001 9:22 PM
To: Dave Cramer
Cc: pgsql-jdbc@postgresql.org
Subject: Re: Todo/missing? (was Re: [ADMIN] High memory usage [PATCH])

Dave,

Can you give a little more detail on what you mean by 'Improved 
DatabaseMetaData'?  What specific areas are currently lacking?

thanks,
--Barry


>>On Mon, Jun 25, 2001 at 10:56:18PM -0400, Dave Cramer wrote:
>>
>>>I have to agree, we need to compile a todo list. 
>>>
>>>Mine would include:
>>>
>>>1) Comprehensive test suite. This may be available already.
>>>2) Updateable resultSet
>>>3) Improved DatabaseMetaData
>>>4) Compatible blob support
>>>
> 
> Added to official PostgreSQL TODO:
> 
> * JDBC
>         * Comprehensive test suite. This may be available already.    
>         * Updateable resultSet     
>         * Improved DatabaseMetaData     
>         * Compatible blob support    
> 
> 




---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

From pgsql-jdbc-owner+M968@postgresql.org Sun Jul  8 18:59:29 2001
Return-path: <pgsql-jdbc-owner+M968@postgresql.org>
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
	by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f68MxTl05403
	for <pgman@candle.pha.pa.us>; Sun, 8 Jul 2001 18:59:29 -0400 (EDT)
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
	by postgresql.org (8.11.3/8.11.1) with SMTP id f68MxWa07043
	for <pgman@candle.pha.pa.us>; Sun, 8 Jul 2001 18:59:32 -0400 (EDT)
	(envelope-from pgsql-jdbc-owner+M968@postgresql.org)
Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17])
	by postgresql.org (8.11.3/8.11.1) with ESMTP id f68MrGa05368
	for <pgsql-jdbc@postgresql.org>; Sun, 8 Jul 2001 18:53:16 -0400 (EDT)
	(envelope-from peter_e@gmx.net)
Received: from fwd06.sul.t-online.de 
	by mailout02.sul.t-online.de with smtp 
	id 15JNQP-0004x9-00; Mon, 09 Jul 2001 00:53:13 +0200
Received: from peter.localdomain (520083510237-0001@[212.185.245.47]) by fmrl06.sul.t-online.com
	with esmtp id 15JNQH-0xfc00C; Mon, 9 Jul 2001 00:53:05 +0200
Date: Mon, 9 Jul 2001 00:55:37 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: <pgsql-jdbc@postgresql.org>
Subject: [JDBC] To do list for DatabaseMetaData
Message-ID: <Pine.LNX.4.30.0107090041240.677-100000@peter.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sender: 520083510237-0001@t-dialin.net
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Since DatabaseMetaData seems to have been a subject of interest lately I
have composed a list of concrete things that need to be done there.

The spec of DatabaseMetaData is here:
http://java.sun.com/j2se/1.3/docs/api/java/sql/DatabaseMetaData.html

All the functions listed in the spec and not listed below I have recently
checked and updated for correctness and compliance.  Thus, this list is
complete.  Functions marked with '?' I have not checked yet.

If someone wants to tackle some of the getThings() functions, a
description of the system catalogs is in the Developer's Guide.  Also note
that some functions currently incorrectly handle the case of null patterns
vs. "" patterns vs. "%" patterns.

At least two parameters obtained by a DatabaseMetaData method are
user-tunable on the server side.  The only way to get at those numbers
currently is to use SHOW and parse the NOTICE: it sends back (which is
impossible in the days of internationalized messages), so a nice
side-project would be to implement a get_config_variable(text) returns
text (better names possible) function to allow easier access.

Now the list:

allProceduresAreCallable()		not all procedures listed are
					callable (triggers, in/out)
allTablesAreSelectable()		should this check access
					privileges or what?
getSQLKeywords()			outdated, could be automated like
					keywords.sgml
getNumericFunctions()			decide what exactly is a "numeric function"?
getStringFunctions()			ditto
getSystemFunctions()			ditto
getTimeDateFunctions()			ditto
getExtraNameCharacters()		server allows \200 to \377, how
					does this fit in with Unicode?
getMaxColumnNameLength()		32 is hard-coded here, maybe query server
getMaxColumnsInIndex()			this should be detected from server
getMaxColumnsInTable()			this limit is probably shaky
getMaxConnections()			could query the server for this
					(SHOW, see above)
getMaxCursorNameLength()		32 hard-coded
getMaxSchemaNameLength()		will be 32 when done
getMaxProcedureNameLength()		32 hard-coded
getMaxCatalogNameLength()		should be NAMEDATALEN
doesMaxRowSizeIncludeBlobs()		since we don't have blobs, should
					this throw an exception?
getMaxStatements()			questionable, see comment there
getMaxTableNameLength()			32 hard-coded
getMaxUserNameLength()			32 hard-coded
getDefaultTransactionIsolation()	This is configurable in 7.2.
					(SHOW, see above)
getProcedures()				missing catalog (database) and
					remarks columns
getProcedureColumns()			only dummy implementation
getTables()				fails to handle pre-7.1 servers
					(relkind 'v')
getSchemas()				This should throw an exception.
getTableTypes()				?
getColumns()				?
getColumnPrivileges()			not implemented
getTablePrivileges()			not implemented
getBestRowIdentifier()			only dummy implementation
getVersionColumns()			not implemented
getPrimaryKeys()			?
getImportedKeys()			?
getExportedKeys()			not implemented
getCrossReference()			not implemented
getTypeInfo()				?
getIndexInfo()				?
getUDTs()				?


-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

From pgsql-general-owner+M14602@postgresql.org Sat Sep  1 00:50:49 2001
Return-path: <pgsql-general-owner+M14602@postgresql.org>
Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f814onF24433
	for <pgman@candle.pha.pa.us>; Sat, 1 Sep 2001 00:50:49 -0400 (EDT)
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
	by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f814pNq39726;
	Fri, 31 Aug 2001 23:51:23 -0500 (CDT)
	(envelope-from pgsql-general-owner+M14602@postgresql.org)
Received: from ns1.austin.rr.com (ns1.austin.rr.com [24.93.35.62])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id f81439f96700
	for <pgsql-general@postgresql.org>; Sat, 1 Sep 2001 00:03:09 -0400 (EDT)
	(envelope-from rsanford@nolimitsystems.com)
Received: from mightywombat (cs662523-179.houston.rr.com [66.25.23.179])
	by ns1.austin.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id f813x7pX027417
	for <pgsql-general@postgresql.org>; Fri, 31 Aug 2001 22:59:07 -0500
From: "Robert J. Sanford, Jr." <rsanford@nolimitsystems.com>
To: <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] PL/java?
Date: Fri, 31 Aug 2001 23:02:04 -0500
Message-ID: <HOEFIONAHHKFEFENBMNOAEPPCBAA.rsanford@nolimitsystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com>
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR

note - i don't work for any of the companies whose products
are mentioned below. i have performed evaluations of these
products and the support provided when attempting to determine
what platform my company's systems should run on. unfortunately,
i did not choose orion and i am suffering for it now...

some goober blathered thusly:
> Have you ever actually used Java on an enterprise-level 
> application?  Ever see the Tomcat webserver?  It uses
> 100MB of memory, drives the load on our server up to 8,
> and doesn't serve nearly as fast apache. Do you really
> want that in your database?

first - don't complain about java because you or someone
in your group/department/company made a poor decision on
what tools to use. that's like complaining about mexican
food when the only experience you have is eating an out-
dated frozen burrito from the 7-11 freezer.

when looking at the performance of java you have to take
a look at two things - first you have to compare various
java implementations against each other and then you have
to compare the best java implementations against native
c/c++ code. the following link does that. the java tests
include tomcat, orion, websphere, and resin. jrun and
weblogic were originally included in the testing but
were both removed at their companies' request.

the tests also compare orion vs microsoft asp running on
win2k and iis5. all tests run on the same hardware.

what i believe these tests clearly demonstrate is that
java is not the problem, the implementation applications
based on java is. i also do not believe that tomcat is
a fair representation of java performance in that it is
intended to be a reference implementation. as such, the
code base should sacrifice performance for clarity.

http://www.orionserver.com/benchmarks/benchmark.html


while not in the benchmark i would also like to
recommend jetty as an app server. it is an opensource,
100% java web and application server. in its base form
it is "just" a web, servlet, and jsp engine. it does,
however, have contributed code providing integration
with other j2ee opensource projects such as the JBoss
EJB engine.

you can find the jetty home page at:
   http://jetty.mortbay.com/

and then they blathered some more:
> Compare the speed of Oracle 8 with 8i if you don't
> believe me.  The stability is also much worse.  Ever
> see a JVM on any platform that didn't crash if you
> looked at it cockeyed?  Ever really trust the garbage
> collection?  I don't.  I've found a memory leak in IBM 
> developed java libraries.  Gotta restart that app
> every once in a while to reclaim system resources it
> gobbled up and never gave back.

some mention was made regarding the performance of
the oracle8i application server. well, oracle has
realized that their performance was sub-optimal and
rectified the situation by licensing the orion server
for oracle9i. while money and politics most certainly
play a part in any licensing arrangement they must
also realize that making customers happy through the
performance of their applications will lead to more
money. the link to the press release is below.

http://www.oracle.com/corporate/press/index.html?759347.html

all of that being said...

i don't think that the person that started this thread
did anything wrong by making the request they did. that
is what opensource is all about - contributions, even
just contributions of ideas, are welcomed. even so, there
are several options that i see for getting it implemented:
1) its an open source project so implement it yourself.
   while i have never worked on modifying the code base
   i am extremely confident that the current developers
   will be more than willing to give you advice and
   pointers.
2) if #1 is not feasible either because you don't have
   the time, the inclination, or the experience then
   you can write a contract that will pay one of the
   postgres developers to implement it for you.
3) if that isn't feasible you can try to get a volunteer
   to do so.
4) if that isn't feasible then you either have to live
   with what you have, go elsewhere, or be quiet.

to the person that blathered thusly in response to the
request for java:
> Merits of the language notwithstanding, I'd rather
> not have a buggy, still under development
> (depreciating everything under the sun with every
> new iteration) JVM parasite in my DB.

informed and intelligent debate is good. given that i
believe such to be true, i would request that you
refrain from blathering such vitriol and uninformed
nonsense. not only is it for the good of the people
on the list who don't want to hear it but it will
also do you good by not telling everyone out there
that you are a very silly person that doesn't deal
with logic and/or facts.

to everyone else on the list - if we all contribute
a penny we could probably buy enough burritos from
7-11 to make sure that his hands and mouth are busy
for a good long while.

rjsjr



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-general-owner+M14597@postgresql.org Fri Aug 31 23:23:15 2001
Return-path: <pgsql-general-owner+M14597@postgresql.org>
Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f813NEF20222
	for <pgman@candle.pha.pa.us>; Fri, 31 Aug 2001 23:23:14 -0400 (EDT)
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
	by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f813Njq38048;
	Fri, 31 Aug 2001 22:23:46 -0500 (CDT)
	(envelope-from pgsql-general-owner+M14597@postgresql.org)
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id f812Yuf42942
	for <pgsql-general@postgresql.org>; Fri, 31 Aug 2001 22:35:04 -0400 (EDT)
	(envelope-from alex@pilosoft.com)
Received: from localhost (alexmail@localhost)
	by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA20075;
	Fri, 31 Aug 2001 22:35:23 -0400 (EDT)
Date: Fri, 31 Aug 2001 22:35:23 -0400 (EDT)
From: Alex Pilosov <alex@pilosoft.com>
To: Alex Knight <knight@phunc.com>
cc: pgsql-general@postgresql.org
Subject: [WAY OT] Re: [GENERAL] PL/java?
In-Reply-To: <MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com>
Message-ID: <Pine.BSO.4.10.10108312220140.19501-100000@spider.pilosoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR

On Fri, 31 Aug 2001, Alex Knight wrote:

> It is generally wiser to split the webservers from the appservers;
> that will save on memory footprints from each respectively. That alone
> can give each machine a specific task to accomplish... generally more
> efficiently. But I would assume you know this.

And it is wise to split database from middleware, and not try to saddle
PostgreSQL with requirements to support Java in-process. _IF_ java stored
procedures are implemented, it should be via something like a) oracle's
extproc (start a separate process to load the function) b) some of perl
java tools (they start a jdk in a separate process and communicate with it
using RMI).


Problem with java-pgsql integration is the threads model: Java really
really wants threads. Postgres doesn't do threads. So if most simple way
is attempted, you will incur overhead of starting up JVM for each backend
(a few seconds as opposed to milliseconds) and non-shared 30M of memory
per backend (as opposed to currently <3 megs of non-shared memory per
backend).

> Using something like WebLogic, WebSphere, or Orion would be a wiser
> approach. For the company with the low budget, Orion is only something
> like $2000, and it has full J2EE support, including EJBs, etc. Try
> finding that kind of richness in Tomcat. Also, Orion takes up only
> 40-50mb at start, which is really fairly reasonable; ram is cheap
> anyways... a server that has to perform complicated algorithms to a
> large audience but has hardly any ram shouldn't be on the internet
> anyways; unless it can handle it.

_ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of
(non-windows, non-java) software that takes 40-50M just to start up!

I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds
to start up on P3-800, that, IMHO, is ridiculous. 

It is not only issue of memory, its easy to throw memory at the problem,
its an issue of _incremental use_ of memory. As you scale 

> I feel that you don't really have enough experience with _java_ to
> judge it accurately. Frankly, the JVM is quite small nowadays,
> considering the amount of base classes that sit in memory much of the
> time. And the JVMs are really much faster these days. Java is still
> slow for 2 reasons: 1) Developers who don't optimize their code as
> they write it, 2) Bytecode interpretation is and probably never will
> be as fast as something like C/C++. But it certainly isn't the JVM
> itself slowing it down because of some "extended memory" that it lives
> in. Any reasonable server should have absolutely no problems if the
> jvm is implemented _properly_ (which many packages do not do), etc. If
> you're comparing Java to perl, yes, certainly it's a bit more of a
> beast, but perl quite simply can't keep up in speed and feature
> richness (when was the last time you secured your perl code in a
> redistributable fashion?)
_WHY_ the heck do all base classes need to be in memory all the time? Why
are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny
compared to all the java standard library. 

You know what the answer to it is: Because they are ALL written in java,
as opposed to more sane languages like perl which handcode their "standard
libraries" or the most important pieces of them in C. 

Perl is far faster than java in about any practical application I did.
Again, the issue is not speed of JVM versus PP (perl virtual machine), if
you did number crunching in perl and java, they would probably be at par.
Its an issue of standard libraries. They are _horribly slow_. Perl's
hashtables are a very nice piece of optimized C code. Java's hashtables
are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog
and a half, because they reimplemented all the things that are commonly
done in C in Java.

> The only mistake the developers can make is poorly implementing the
> jvm, but most certainly not Java itself. I've been working on
> architecting and building enterprise level sites and applications for
> nearly 8 years now, and I've seen too many people try to implement
> perl cgi websites for enterprise sites and watch them choke and crawl
> to their knees because of poor system resource handling, lack of
> scalability, etc... I most certainly don't consider a single webserver
> with an appserver and tiny database to be enterprise level either (not
> that I'm inferring you said it was).
You cannot compare a perl CGI script and a J2EE server. Its like comparing
a webserver you wrote yourself vs apache! There are application servers
(or more closely, code libraries) for perl that match what J2EE provides. 

--
Alex Pilosov            | http://www.acedsl.com/home.html
CTO - Acecape, Inc.     | AceDSL:The best ADSL in the world
325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
New York, NY 10018      |


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org Thu Oct 25 22:24:44 2001
Return-path: <pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org>
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f9Q1Oim04694
	for <pgman@candle.pha.pa.us>; Thu, 25 Oct 2001 21:24:44 -0400 (EDT)
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id f9Q1CeR31737
	for <pgman@candle.pha.pa.us>; Thu, 25 Oct 2001 20:21:26 -0500 (CDT)
	(envelope-from pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org)
Received: from smaug.polygnosis.com (smaug.polygnosis.com [195.139.160.201])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id f9Q16NP39474
	for <pgsql-hackers@postgresql.org>; Thu, 25 Oct 2001 21:06:23 -0400 (EDT)
	(envelope-from gunnar@smaug.polygnosis.com)
Received: (from gunnar@localhost)
	by smaug.polygnosis.com (8.11.0/8.11.0) id f9Q15nC01560;
	Fri, 26 Oct 2001 03:05:49 +0200
To: tweekie <None@news.tht.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] java virtual machine
References: <3bd825e2_1@Usenet.com>
From: Gunnar =?iso-8859-1?q?R=F8nning?= <gunnar@polygnosis.com>
Date: 26 Oct 2001 03:05:49 +0200
In-Reply-To: <3bd825e2_1@Usenet.com>
Message-ID: <m28zdzmcr6.fsf@smaug.polygnosis.com>
Lines: 19
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

* tweekie <None@news.tht.net> wrote:
|
| I asked this question a while back but got no response - is there any way of 
| creating a Java stored procedure in a postgres database ? I can see that 
| there is a built-in PL/sql type of environment and a python one but it would  
| be nice if I could migrate Java stored procedures in an Oracle database into  
| postgres.
| 
| Any comments?


It would rock ;-) An Hungarian guy just sent a mail indicating that he
had a first prototype version of something with Kaffe up and running.
But I believe there is a lot of issues to be solved, especially
threading issues...

-- 
Gunnar R�nning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

From pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org Mon Dec  3 13:53:24 2001
Return-path: <pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB3IrNS29264
	for <pgman@candle.pha.pa.us>; Mon, 3 Dec 2001 13:53:24 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB3IrO213373
	for <pgman@candle.pha.pa.us>; Mon, 3 Dec 2001 13:53:24 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB3Iq1N35610
	for <pgman@candle.pha.pa.us>; Mon, 3 Dec 2001 12:52:02 -0600 (CST)
	(envelope-from pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fAU95km73601
	for <pgsql-general@postgresql.org>; Fri, 30 Nov 2001 04:05:46 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA11457
	for <pgsql-general@postgresql.org>; Fri, 30 Nov 2001 10:05:45 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C074DE4.9040905@freemail.hu>
Date: Fri, 30 Nov 2001 10:14:12 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: [GENERAL] java stored procedures
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR

Hi!

A few months ago I asked if anyone started working on PL/JAVA, the 
ansver was no. Now I started to write a java stored procedure language 
and environment for PostgreSQL. Some code is already working, and it is 
geting interresting. So, I would like to ask you to write me your ideas, 
suggestions, etc for this environment.
The source code will be available under GPL when it is worth for 
distributing it (this will take for a while).
thanks.

Laszlo Hornyak


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

From pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org Tue Dec  4 13:14:09 2001
Return-path: <pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB4IE3r15972
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 13:14:04 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB4IE2Y07122
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 13:14:02 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB4I9HN76662
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:09:17 -0600 (CST)
	(envelope-from pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org)
Received: from belphigor.mcnaught.org ([216.151.155.121])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4Hwsm96365;
	Tue, 4 Dec 2001 12:58:59 -0500 (EST)
	(envelope-from doug@wireboard.com)
Received: (from doug@localhost)
	by belphigor.mcnaught.org (8.11.6/8.9.3) id fB4Hwlo07786;
	Tue, 4 Dec 2001 12:58:47 -0500
X-Authentication-Warning: belphigor.mcnaught.org: doug set sender to doug@wireboard.com using -f
To: Barry Lind <barry@xythos.com>
cc: Laszlo Hornyak <hornyakl@freemail.hu>, pgsql-general@postgresql.org,
   pgsql-jdbc@postgresql.org
Subject: Re: [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com>
	<3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com>
From: Doug McNaught <doug@wireboard.com>
Date: 04 Dec 2001 12:58:47 -0500
In-Reply-To: Barry Lind's message of "Tue, 04 Dec 2001 08:44:50 -0800"
Message-ID: <m3itbmeujs.fsf@belphigor.mcnaught.org>
Lines: 42
User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (20 Minutes to Nikko)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR

Barry Lind <barry@xythos.com> writes:

> Having one jvm that all the postgres backend processes communicate with makes
> the whole feature much more complicated, but is necessary in my opinion.

Agreed.  Also, the JVM is a multithreaded app, and running it inside a
non-threaded program (the backend) might cause problems. 

> Then the question becomes how does the jvm process interact with the database
> since they are two different processes.  You will need some sort of
> interprocess communication between the two to execute sql statements.  This
> could be accomplished by using the existing jdbc driver.  But the bigest
> problem here is getting the transaction semantics right.  How does a sql
> statement being run by a java stored procedure get access to the same
> connection/transaction as the original client?  What you don't want happening
> is that sql issued in a stored java procedure executes in a different
> transaction as the caller, what would rollback of the stored function call
> mean in that case?

I think you would have to to expose the SPI layer to Java running in a
separate process, either using an RMI server written in C or a custom
protocol over a TCP socket (Java of course can't do Unix sockets).
This raises some thorny issues of authentication and security but I
don't think they're insurmountable.  You could, for example, create a
cryptographically strong "cookie" in the backend when a Java function
is called.  The cookie would be passed to the Java function when it
gets invoked, and then must be passed back to the SPI layer in order
for the latter to accept the call.  A bit clunky but should be safe as
far as I can see.

The cookie would be needed anyhow, I think, in order for the SPI layer 
to be able to find the transaction that the Java function was
originally invoked in.

You could make the SPI layer stuff look like a normal JDBC driver to
user code--PL/Perl does this kind of thing with the Perl DBI
interface.

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

From pgsql-jdbc-owner+M2545@postgresql.org Tue Dec  4 12:49:03 2001
Return-path: <pgsql-jdbc-owner+M2545@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB4Hn1r09487
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:49:01 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB4HmxY25870
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:48:59 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB4HiLN75867;
	Tue, 4 Dec 2001 11:44:21 -0600 (CST)
	(envelope-from pgsql-jdbc-owner+M2545@postgresql.org)
Received: from barry.xythos.com ([64.139.0.223])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4H9bm94568;
	Tue, 4 Dec 2001 12:09:38 -0500 (EST)
	(envelope-from barry@xythos.com)
Received: from xythos.com (localhost.localdomain [127.0.0.1])
	by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB4Gior02314;
	Tue, 4 Dec 2001 08:44:50 -0800
Message-ID: <3C0CFD82.1030600@xythos.com>
Date: Tue, 04 Dec 2001 08:44:50 -0800
From: Barry Lind <barry@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: Laszlo Hornyak <hornyakl@freemail.hu>
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Laszlo,

I think it would help a lot if you could take a little time to write 
down what your planned architecture for a pljava would be.  It then 
becomes much easier for myself and probably others reading these lists 
to make suggestions on ways to improve what you are planning (or 
possible problems with your strategy).  Without knowing what exactly you 
are thinking of doing it is difficult to comment.

But let me try throwing out a few thoughts about how I think this should 
be done.

First question is how will the jvm be run?  Since postgres is a 
multiprocess implementation (i.e. each connection has a separate process 
on the server) and since java is a multithreaded implementation (i.e. 
one process supporting multiple threads), what should the pljava 
implementation look like?  I think there should be a single jvm process 
for the entire db server that each postgresql process connects to 
through sockets/rmi.  It will be too expensive to create a new jvm 
process for each postgresql connection (expensive in both terms of 
memory and cpu, since the startup time for the jvm is significant and it 
requires a lot of memory).

Having one jvm that all the postgres backend processes communicate with 
makes the whole feature much more complicated, but is necessary in my 
opinion.

Then the question becomes how does the jvm process interact with the 
database since they are two different processes.  You will need some 
sort of interprocess communication between the two to execute sql 
statements.  This could be accomplished by using the existing jdbc 
driver.  But the bigest problem here is getting the transaction 
semantics right.  How does a sql statement being run by a java stored 
procedure get access to the same connection/transaction as the original 
client?  What you don't want happening is that sql issued in a stored 
java procedure executes in a different transaction as the caller, what 
would rollback of the stored function call mean in that case?

I am very interested in hearing what your plans are for pl/java.  I 
think this is a very difficult project, but one that would be very 
useful and welcome.

thanks,
--Barry




Laszlo Hornyak wrote:

> Hi!
> 
> I am such a lame in the licensing area. As much as I know, BSD license 
> is more free than GPL. I think it is too early to think about licensing, 
> but it`s ok, you won :), when it will be ready(or it will seem to get 
> closer to a working thing, currently it looks more like a interresting 
> test), I will ask you if you want to distribute it with Postgres, and if 
> you say yes, the license will be the same as Postgresql`s license. 
> Anyway is this neccessary when it is the part of the distribution?
> Is this ok for you?
> 
> thanks,
> Laszlo Hornyak
> 
> ps: still waiting for your ideas, suggestions, etc :) I am not memeber 
> of the mailing list, please write me dirrectly!
> 
> Barry Lind wrote:
> 
>> Laszlo,
>>
>> In my mind it would be more useful if this code was under the same 
>> license as the rest of postgresql.  That way it could become part of 
>> the product as opposed to always being a separate component.  (Just 
>> like plpgsql, pltcl and the other procedural languages).
>>
>> thanks,
>> --Barry
>>
>>
> 
> 



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

From pgsql-jdbc-owner+M2555@postgresql.org Thu Dec  6 10:16:31 2001
Return-path: <pgsql-jdbc-owner+M2555@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6FGUZ29382
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:16:30 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6FGTE25863
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:16:29 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6F9lN55201;
	Thu, 6 Dec 2001 09:09:48 -0600 (CST)
	(envelope-from pgsql-jdbc-owner+M2555@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4JB2m99252;
	Tue, 4 Dec 2001 14:11:03 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA07040;
	Tue, 4 Dec 2001 20:10:17 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C0D219C.1090804@freemail.hu>
Date: Tue, 04 Dec 2001 20:18:52 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: Barry Lind <barry@xythos.com>
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Hi!

Barry Lind wrote:

> Laszlo,
>
> I think it would help a lot if you could take a little time to write 
> down what your planned architecture for a pljava would be.  It then 
> becomes much easier for myself and probably others reading these lists 
> to make suggestions on ways to improve what you are planning (or 
> possible problems with your strategy).  Without knowing what exactly 
> you are thinking of doing it is difficult to comment. 

>
>
> But let me try throwing out a few thoughts about how I think this 
> should be done.
>
> First question is how will the jvm be run?  Since postgres is a 
> multiprocess implementation (i.e. each connection has a separate 
> process on the server) and since java is a multithreaded 
> implementation (i.e. one process supporting multiple threads), what 
> should the pljava implementation look like?  I think there should be a 
> single jvm process for the entire db server that each postgresql 
> process connects to through sockets/rmi.  It will be too expensive to 
> create a new jvm process for each postgresql connection (expensive in 
> both terms of memory and cpu, since the startup time for the jvm is 
> significant and it requires a lot of memory). 

I absolutely agree. OK, it`s done.

So, a late-night-brainstorming here:
What I would like to see in PL/JAVA is the object oriented features, 
that makes postgresql nice. Creating a new table creates a new class in 
the java side too. Instantiating an object of the newly created class 
inserts a row into the table. In postgresql tables can be inherited, and 
this could be easyly done by pl/java too. I think this would look nice.
But this is not the main feature. Why I would like to see a nice java 
procedural language inside postgres is java`s advanced communication 
features (I mean CORBA, jdbc, other protocols). This is the sugar in the 
caffe.

I am very far from features like this.
PL/JAVA now:
-there is a separate process running java (kaffe). this process creates 
a sys v message queue, that holds requests. almost forgot, a shared 
memory segment too. I didn`t find better way to tell postgres the 
informations about the java process.
-the java request_handler function on the server side attaches to the 
shared memory, reads the key of the message queue., attaches to it, 
sends the data of the function, and a signal for the pl/java. after, it 
is waiting for a signal from the java thread.
-when java thread receives the signal, it reads the message(s) from the 
queue, and starts some actions. When done it tells postgres with a 
signal that it is ready, and it can come for its results. This will be 
rewritten see below problems.
-And postgres is runing, while java is waiting for postgres to say 
something.

Threading on the java process side is not done yet, ok, it is not that 
hard, I will write it, if it will be realy neccessary.

The problems, for now:
I had a very simple system, that passed a very limited scale of argument 
types, with a very limited quantity of parameters (int, varchar, bool). 
Postgres has limits for the argument count too, but not for types. It 
had too much limits, so I am working (or to tell the truth now only 
thinking) on a new type handling that fits the felxibility of 
Postgresql`s type flexibility. For this I will have to learn a lot about 
Postgres`s type system. This will be my program this weekend. :)

thanks,
Laszlo Hornyak


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

From pgsql-jdbc-owner+M2549@postgresql.org Tue Dec  4 22:34:48 2001
Return-path: <pgsql-jdbc-owner+M2549@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB53Ykr17433
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 22:34:47 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB53YkY26794
	for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 22:34:46 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB53UcN93073;
	Tue, 4 Dec 2001 21:30:38 -0600 (CST)
	(envelope-from pgsql-jdbc-owner+M2549@postgresql.org)
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB53Obm35215;
	Tue, 4 Dec 2001 22:24:37 -0500 (EST)
	(envelope-from barry@xythos.com)
Received: from xythos.com (localhost.localdomain [127.0.0.1])
	by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB51YLJ03883;
	Tue, 4 Dec 2001 17:34:21 -0800
Message-ID: <3C0D799D.4010808@xythos.com>
Date: Tue, 04 Dec 2001 17:34:21 -0800
From: Barry Lind <barry@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: hornyakl@users.sourceforge.net
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Laszlo,


> I am very far from features like this.
> PL/JAVA now:
> -there is a separate process running java (kaffe). this process creates 
> a sys v message queue, that holds requests. almost forgot, a shared 
> memory segment too. I didn`t find better way to tell postgres the 
> informations about the java process.


Does the mechanism you are planning support running any JVM?  In my 
opionion Kaffe isn't good enough to be widely useful.  I think you 
should be able to plugin whatever jvm is best on your platform, which 
will likely be either the Sun or IBM JVMs.

Also, can you explain this a little bit more.  How does the jvm process 
get started? (I would hope that the postgresql server processes would 
start it when needed, as opposed to requiring that it be started 
separately.)  How does the jvm access these shared memory structures? 
Since there aren't any methods in the java API to do such things that I 
am aware of.

> -the java request_handler function on the server side attaches to the 
> shared memory, reads the key of the message queue., attaches to it, 
> sends the data of the function, and a signal for the pl/java. after, it 
> is waiting for a signal from the java thread.


I don't understand how you do this in java?  I must not be understanding 
  something correctly here.

> -when java thread receives the signal, it reads the message(s) from the 
> queue, and starts some actions. When done it tells postgres with a 
> signal that it is ready, and it can come for its results. This will be 
> rewritten see below problems.


Are signals the best way to accomplish this?

> -And postgres is runing, while java is waiting for postgres to say 
> something.


But in reality if the postgres process is executing a stored function it 
needs to wait for the result of that function call before continuing 
doesn't it?

> 
> Threading on the java process side is not done yet, ok, it is not that 
> hard, I will write it, if it will be realy neccessary.


Agreed, this is important.

> 
> The problems, for now:
> I had a very simple system, that passed a very limited scale of argument 
> types, with a very limited quantity of parameters (int, varchar, bool). 
> Postgres has limits for the argument count too, but not for types. It 
> had too much limits, so I am working (or to tell the truth now only 
> thinking) on a new type handling that fits the felxibility of 
> Postgresql`s type flexibility. For this I will have to learn a lot about 
> Postgres`s type system. This will be my program this weekend. :)


Shouldn't this code use all or most of the logic found in the FE/BE 
protocol?  Why invent and code another mechanism to transfer data when 
one already exists.  (I will admit that the current FE/BE mechanism 
isn't the ideal choice, but it seems easier to reuse what exists for now 
and improve on it later).


> 
> thanks,
> Laszlo Hornyak
> 

You didn't mention how you plan to deal with the transaction symantics. 
  So what happens when the pl/java function calls through jdbc back to 
the server to insert some data?  That should happen in the same 
transaction as the caller correct?

thanks,
--Barry


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

From pgsql-jdbc-owner+M2559@postgresql.org Thu Dec  6 10:18:55 2001
Return-path: <pgsql-jdbc-owner+M2559@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6FIrZ29672
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:18:54 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6FIrE26972
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:18:53 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6F9nN55205;
	Thu, 6 Dec 2001 09:09:49 -0600 (CST)
	(envelope-from pgsql-jdbc-owner+M2559@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB58wVm49422;
	Wed, 5 Dec 2001 03:58:31 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA12365;
	Wed, 5 Dec 2001 09:57:35 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C0DE382.1050400@freemail.hu>
Date: Wed, 05 Dec 2001 10:06:10 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: Barry Lind <barry@xythos.com>
cc: hornyakl@users.sourceforge.net, pgsql-general@postgresql.org,
   pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Hi!

Barry Lind wrote:

> Does the mechanism you are planning support running any JVM?  In my 
> opionion Kaffe isn't good enough to be widely useful.  I think you 
> should be able to plugin whatever jvm is best on your platform, which 
> will likely be either the Sun or IBM JVMs.

Ok, I also had problems with caffe, but it may work. I like it becouse 
it is small (the source is about 6M). As much as I know Java VM`s has a 
somewhat standard native interface called JNI. I use this to start the 
VM, and communicate with it. If you think I should change I will do it, 
but it may take a long time to get the new VM. For then I have to run kaffe.

> Also, can you explain this a little bit more.  How does the jvm 
> process get started? (I would hope that the postgresql server 
> processes would start it when needed, as opposed to requiring that it 
> be started separately.)  How does the jvm access these shared memory 
> structures? Since there aren't any methods in the java API to do such 
> things that I am aware of.

JVM does not. 'the java process' does with simple posix calls. I use 
debian potatoe, on any other posix system it should work, on any other 
somewhat posix compatible system it may work, I am not sure...

>
> I don't understand how you do this in java?  I must not be 
> understanding  something correctly here.

My failure.
The 'java request_handler' is not a java function, it is the C 
call_handler in the Postgres side, that is started when a function of 
language 'pljava' is called.
I made some failure in my previous mail. At home I named the pl/java 
language pl/pizza (something that is not caffe, but well known enough 
:). The application has two running binaries:
-pizza (which was called 'java process' last time) This is a small C 
program that uses JNI to start VM and call java methods.
-plpizza.so the shared object that contains the call_handler function.


>
>
>> -when java thread receives the signal, it reads the message(s) from 
>> the queue, and starts some actions. When done it tells postgres with 
>> a signal that it is ready, and it can come for its results. This will 
>> be rewritten see below problems.
>
>
>
> Are signals the best way to accomplish this? 

I don`t know if it is the best, it is the only way I know :)
Do you know any other ways?

>
>
>> -And postgres is runing, while java is waiting for postgres to say 
>> something.
>
> But in reality if the postgres process is executing a stored function 
> it needs to wait for the result of that function call before 
> continuing doesn't it? 

Surely, this is done. How could Postgres tell the result anyway ? :)

>
>>
>> Threading on the java process side is not done yet, ok, it is not 
>> that hard, I will write it, if it will be realy neccessary.
>
> Agreed, this is important.
>
> Shouldn't this code use all or most of the logic found in the FE/BE 
> protocol?  Why invent and code another mechanism to transfer data when 
> one already exists.  (I will admit that the current FE/BE mechanism 
> isn't the ideal choice, but it seems easier to reuse what exists for 
> now and improve on it later). 

Well, I am relatively new to Postgres, and I don`t know these protocols. 
In the weekend I will start to learn it, and in Sunday or Monday I maybe 
I will understand it, if not, next weekend..

>
> You didn't mention how you plan to deal with the transaction 
> symantics.  So what happens when the pl/java function calls through 
> jdbc back to the server to insert some data?  That should happen in 
> the same transaction as the caller correct? 

I don`t think this will be a problem, I have ideas for this. Idea mean: 
I know how I will start it, it may be good, or it may be fataly stupid 
idea, it will turn out when I tried it. Simply: The same way plpizza 
tells pizza the request, pizza can talk back to plpizza. This is planed 
to work with similar mechanism I described last time (shm+signals).

Monday I will try to send a little pieces of code to make thing clear, ok?

thanks,
Laszlo Hornyak


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

From pgsql-jdbc-owner+M2567@postgresql.org Thu Dec  6 12:05:50 2001
Return-path: <pgsql-jdbc-owner+M2567@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6H5nZ07357
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 12:05:49 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6H5ma17427
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 12:05:48 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6H1DN59312;
	Thu, 6 Dec 2001 11:01:13 -0600 (CST)
	(envelope-from pgsql-jdbc-owner+M2567@postgresql.org)
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6Gtsm73872;
	Thu, 6 Dec 2001 11:55:55 -0500 (EST)
	(envelope-from barry@xythos.com)
Received: from xythos.com (localhost.localdomain [127.0.0.1])
	by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB5HWJ902835;
	Wed, 5 Dec 2001 09:32:19 -0800
Message-ID: <3C0E5A23.7060701@xythos.com>
Date: Wed, 05 Dec 2001 09:32:19 -0800
From: Barry Lind <barry@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: hornyakl@users.sourceforge.net
cc: pgsql-hackers@postgresql.org, pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com> <3C0DE382.1050400@freemail.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org
Status: OR

Laszlo,

I have cc'ed the hackers mail list since that group of developers is 
probably better able than I to make suggestions on the best interprocess 
communication mechanism to use for this.  See 
http://archives2.us.postgresql.org/pgsql-general/2001-12/msg00092.php 
for background on this thread.

I also stopped cc'ing the general list, since this is getting too 
detailed for most of the members on that list.

Now to your mail:

Laszlo Hornyak wrote:

> Hi!
> 
> Barry Lind wrote:
> 
>> Does the mechanism you are planning support running any JVM?  In my 
>> opionion Kaffe isn't good enough to be widely useful.  I think you 
>> should be able to plugin whatever jvm is best on your platform, which 
>> will likely be either the Sun or IBM JVMs.
> 
> 
> Ok, I also had problems with caffe, but it may work. I like it becouse 
> it is small (the source is about 6M). As much as I know Java VM`s has a 
> somewhat standard native interface called JNI. I use this to start the 
> VM, and communicate with it. If you think I should change I will do it, 
> but it may take a long time to get the new VM. For then I have to run 
> kaffe.
> 


This seems like a reasonable approach and should work across different 
JVMs.  It would probably be a good experiment to try this with the Sun 
or IBM jvm at some point to verify.  What I was afraid of was that you 
were hacking the Kaffe code to perform the integration which would limit 
this solution to only using Kaffe.


>> Also, can you explain this a little bit more.  How does the jvm 
>> process get started? (I would hope that the postgresql server 
>> processes would start it when needed, as opposed to requiring that it 
>> be started separately.)  How does the jvm access these shared memory 
>> structures? Since there aren't any methods in the java API to do such 
>> things that I am aware of.
> 
> 
> JVM does not. 'the java process' does with simple posix calls. I use 
> debian potatoe, on any other posix system it should work, on any other 
> somewhat posix compatible system it may work, I am not sure...
> 
>>
>> I don't understand how you do this in java?  I must not be 
>> understanding  something correctly here.
> 
> 
> My failure.
> The 'java request_handler' is not a java function, it is the C 
> call_handler in the Postgres side, that is started when a function of 
> language 'pljava' is called.
> I made some failure in my previous mail. At home I named the pl/java 
> language pl/pizza (something that is not caffe, but well known enough 
> :). The application has two running binaries:
> -pizza (which was called 'java process' last time) This is a small C 
> program that uses JNI to start VM and call java methods.
> -plpizza.so the shared object that contains the call_handler function.
> 


Just a suggestion:  PL/J might be a good name, since as you probably 
know it can't be called pl/java because of the trademark restrictions on 
the word 'java'.

I am a little concerned about the stability and complexity of having 
this '-pizza' program be responsible for handling the calls on the java 
side.  My concern is that this will need to be a multithreaded program 
since multiple backends will concurrently be needing to interact with 
multiple java threads through this one program.  It might be simpler if 
each postgres process directly communicated to a java thread via a tcpip 
socket.  Then the "-pizza" program would only need to be responsible for 
starting up the jvm and creating java threads and sockets for a postgres 
process (it would perform a similar role to postmaster for postgres 
client connections).


> 
>>
>>
>>> -when java thread receives the signal, it reads the message(s) from 
>>> the queue, and starts some actions. When done it tells postgres with 
>>> a signal that it is ready, and it can come for its results. This will 
>>> be rewritten see below problems.
>>
>>
>>
>>
>> Are signals the best way to accomplish this? 
> 
> 
> I don`t know if it is the best, it is the only way I know :)
> Do you know any other ways?
> 


I don't know, but hopefully someone on the hackers list will chip in 
here with a comment.


>>
>>>
>>> Threading on the java process side is not done yet, ok, it is not 
>>> that hard, I will write it, if it will be realy neccessary.
>>
>>
>> Agreed, this is important.
>>
>> Shouldn't this code use all or most of the logic found in the FE/BE 
>> protocol?  Why invent and code another mechanism to transfer data when 
>> one already exists.  (I will admit that the current FE/BE mechanism 
>> isn't the ideal choice, but it seems easier to reuse what exists for 
>> now and improve on it later). 
> 
> 
> Well, I am relatively new to Postgres, and I don`t know these protocols. 
> In the weekend I will start to learn it, and in Sunday or Monday I maybe 
> I will understand it, if not, next weekend..
> 
>>
>> You didn't mention how you plan to deal with the transaction 
>> symantics.  So what happens when the pl/java function calls through 
>> jdbc back to the server to insert some data?  That should happen in 
>> the same transaction as the caller correct? 
> 
> 
> I don`t think this will be a problem, I have ideas for this. Idea mean: 
> I know how I will start it, it may be good, or it may be fataly stupid 
> idea, it will turn out when I tried it. Simply: The same way plpizza 
> tells pizza the request, pizza can talk back to plpizza. This is planed 
> to work with similar mechanism I described last time (shm+signals).
> 


OK, so the same backend process that called the function gets messaged 
to process the sql.  This should work.  However it means you will need a 
special version of the jdbc driver that uses this shm+signals 
communication mechanism instead of what the current jdbc driver does. 
This is something I would be happy to help you with.



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

From pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org Thu Dec  6 10:11:27 2001
Return-path: <pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6FBQZ28795
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:11:26 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6FBPE23613
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:11:25 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6F5MR55091
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 09:08:01 -0600 (CST)
	(envelope-from pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB5JWMm92521;
	Wed, 5 Dec 2001 14:32:26 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA20333;
	Wed, 5 Dec 2001 20:30:51 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C0E77F0.5030904@freemail.hu>
Date: Wed, 05 Dec 2001 20:39:28 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: Barry Lind <barry@xythos.com>, pgsql-hackers@postgresql.org,
   pgsql-jdbc@postgresql.org
Subject: Re: [HACKERS] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com> <3C0DE382.1050400@freemail.hu> <3C0E5A23.7060701@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Barry Lind wrote:

>
> I also stopped cc'ing the general list, since this is getting too 
> detailed for most of the members on that list.

Ok.

> Now to your mail:
>
> This seems like a reasonable approach and should work across different 
> JVMs.  It would probably be a good experiment to try this with the Sun 
> or IBM jvm at some point to verify.  What I was afraid of was that you 
> were hacking the Kaffe code to perform the integration which would 
> limit this solution to only using Kaffe. 

I am sure they wont work the same way. I think I have a sun jdk 1.3.0-2, 
so I will try to port it soon. The IBM implementation must wait I think 
until january.

>
> Just a suggestion:  PL/J might be a good name, since as you probably 
> know it can't be called pl/java because of the trademark restrictions 
> on the word 'java'. 

Ok, you won, I do not read the licenses. From now it`s name is pl/j. 
Isn`t 'j' too short for the name of the process that runns java? :)

>
> I am a little concerned about the stability and complexity of having 
> this '-pizza' program be responsible for handling the calls on the 
> java side.  My concern is that this will need to be a multithreaded 
> program since multiple backends will concurrently be needing to 
> interact with multiple java threads through this one program.  It 
> might be simpler if each postgres process directly communicated to a 
> java thread via a tcpip socket.  Then the "-pizza" program would only 
> need to be responsible for starting up the jvm and creating java 
> threads and sockets for a postgres process (it would perform a similar 
> role to postmaster for postgres client connections). 

With good design we can solve stability problems. As much as I know, if 
postmaster dies, the postgres server becomes unavailable, this looks the 
same problem. I do not know if we realy need sockets. Anyway, if 'j' 
dies, we can create a new one, and restart calculations. Some watchdog 
functionality...
Doing thing with sockets need a lot of rework. It is the best time for 
this, while there is not too much thing done.

>>>
>>>> -when java thread receives the signal, it reads the message(s) from 
>>>> the queue, and starts some actions. When done it tells postgres 
>>>> with a signal that it is ready, and it can come for its results. 
>>>> This will be rewritten see below problems.
>>>
>>> Are signals the best way to accomplish this? 
>>
>> I don`t know if it is the best, it is the only way I know :)
>> Do you know any other ways?
>>
> I don't know, but hopefully someone on the hackers list will chip in 
> here with a comment.

After a first developement cycle (if my brain doesn`t burn down), the 
signals can be replaced to a plugable communication interface I think. 
So maybe we can use CORBA, or sockets, or something else. This will take 
a lot of time.

> OK, so the same backend process that called the function gets messaged 
> to process the sql.  This should work.  However it means you will need 
> a special version of the jdbc driver that uses this shm+signals 
> communication mechanism instead of what the current jdbc driver does. 
> This is something I would be happy to help you with.


This is kind of you. :)
For this, I will have to finish the protocol of communication. I have to 
learn Postgres enough, so I am not sure this will be done this weekend. 
I have ideas, only time is needed to implement them or to recognize the 
failures.

Thanks,
Laszlo Hornyak



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

From pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org Thu Dec  6 10:01:29 2001
Return-path: <pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6F1RZ28000
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:01:27 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6F1OE19111
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:01:25 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6EvtR54729
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 08:59:16 -0600 (CST)
	(envelope-from pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6EFfm64066;
	Thu, 6 Dec 2001 09:15:41 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA29094;
	Thu, 6 Dec 2001 15:15:01 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C0F7F6B.2060605@freemail.hu>
Date: Thu, 06 Dec 2001 15:23:39 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: Gunnar =?ISO-8859-1?Q?R=F8nning?= <gunnar@polygnosis.com>
cc: Barry Lind <barry@xythos.com>, pgsql-hackers@postgresql.org,
   pgsql-jdbc@postgresql.org
Subject: Re: [HACKERS] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com>	<3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <m2zo4wttp1.fsf@smaug.polygnosis.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Hi!

Sorry, I have time only for short ansvers, it is company time :((.

Gunnar R�nning wrote:

>* Barry Lind <barry@xythos.com> wrote:
>|
>| possible problems with your strategy).  Without knowing what exactly
>| you are thinking of doing it is difficult to comment.
>
>Agreed. 
>
Ok, I will try to bring the code here before Monday, or at least some 
pieces. It is full of hardcoded constants from my developement 
environment. :(


>
>| I am very interested in hearing what your plans are for pl/java.  I
>| think this is a very difficult project, but one that would be very
>| useful and welcome.
>
>I would very much like to hear about the plans myself. 
>
I do not see so big difficulities yet, am I so lame? It won`t be easy, 
realy, we should keep it simple, at least becouse of me.


thanks,
Laszlo Hornyak


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org Thu Dec  6 16:11:23 2001
Return-path: <pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB6LBLZ25078
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 16:11:22 -0500 (EST)
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB6LBMa12305
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 16:11:22 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB6L6wR66812
	for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 15:08:01 -0600 (CST)
	(envelope-from pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org)
Received: from rh72.home.ee (adsl895.estpak.ee [213.168.23.133])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6Kxtm98840;
	Thu, 6 Dec 2001 15:59:55 -0500 (EST)
	(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost.localdomain [127.0.0.1])
	by rh72.home.ee (8.11.6/8.11.6) with ESMTP id fB6I2pn02024;
	Thu, 6 Dec 2001 23:02:52 +0500
Message-ID: <3C0FB2CB.90901@tm.ee>
Date: Thu, 06 Dec 2001 23:02:51 +0500
From: Hannu Krosing <hannu@tm.ee>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: et, en-us
MIME-Version: 1.0
To: hornyakl@users.sourceforge.net
cc: Gunnar =?ISO-8859-1?Q?R=F8nning?= <gunnar@polygnosis.com>,
   Barry Lind 
	<barry@xythos.com>, pgsql-hackers@postgresql.org,
   pgsql-jdbc@postgresql.org
Subject: Re: [HACKERS] [GENERAL] java stored procedures
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com>	<3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <m2zo4wttp1.fsf@smaug.polygnosis.com> <3C0F7F6B.2060605@freemail.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Laszlo Hornyak wrote:

>>
>> | I am very interested in hearing what your plans are for pl/java.  I
>> | think this is a very difficult project, but one that would be very
>> | useful and welcome.
>>
>> I would very much like to hear about the plans myself.
>
> I do not see so big difficulities yet, am I so lame? It won`t be easy, 
> realy, we should keep it simple, at least becouse of me.

Let me propose a very different approach to PL/J - use gcc-java and 
figure out the problems
with (dynamic) compiling and dynamic linking.

This is an approach somewhat similar to .NET/C# that you first compile 
things and then run instead
of trying to do both at the same time ;)

Oracle /may/ be doing something similar with their java stored 
procedures, as they claim these to be "compiled".

-----------------
Hannu



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-hackers-owner+M17140@postgresql.org Thu Jan  3 09:13:32 2002
Return-path: <pgsql-hackers-owner+M17140@postgresql.org>
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g03EDVc00444
	for <pgman@candle.pha.pa.us>; Thu, 3 Jan 2002 09:13:31 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id g03E41N54463;
	Thu, 3 Jan 2002 08:04:01 -0600 (CST)
	(envelope-from pgsql-hackers-owner+M17140@postgresql.org)
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id g01Csdm40742
	for <pgsql-hackers@postgresql.org>; Tue, 1 Jan 2002 07:54:39 -0500 (EST)
	(envelope-from hornyakl@freemail.hu)
Received: from freemail.hu ([192.168.0.200])
	by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA14425;
	Tue, 1 Jan 2002 13:54:35 +0100
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
Message-ID: <3C31B3B7.6030703@freemail.hu>
Date: Tue, 01 Jan 2002 14:03:51 +0100
From: Laszlo Hornyak <hornyakl@freemail.hu>
Reply-To: hornyakl@users.sourceforge.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: hu, en-us
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org, ssutjiono@wc-group.com
Subject: [HACKERS] PL/(pg)J
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR

Happy new year for all!

I would like to tell you about the results of my work on pl/j.
memo: Java and postgres must run in a separate address space. First I 
wanted to use the sys v ipc, which was a bad idea becouse of some 
problems with java VM-s. Many hackers told me about its bad sides, and 
the good sides of the sockets, so I droped the whole code and started a 
new one.

I started to write the java side first, which is maybe almost 10% ready :))
-we have is a communication protocol between the two process. I know 
noone will like it, so there is an API for protocols, so it is plugable. 
The current implementation is receiveing calls,sends exceptions, but 
sending the results is not implemented yet.

-the Postgres side is not yet done. It sends function calls without 
arguments, it doesn`t receive sql queries, exceptions or results at all, 
and there is no API for it, it is an uggly hardcoded thing.

-there is no JDBC implementation, and I have never written JDBC driver, 
so it may take for a while...

But it says "hello world" :))

Todo for me:

-learn more about postgres, jdbc drivers, etc, etc
-develop api for the postgres side of the communication.

This will take for a good while becouse of other todos but I hope next 
time I can tell you good news.

thx,
Laszlo Hornyak


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

From pgsql-general-owner+M19758=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 11:33:11 2002
Return-path: <pgsql-general-owner+M19758=candle.pha.pa.us=pgman@postgresql.org>
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
	by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NGXAU13298
	for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 11:33:10 -0500 (EST)
Received: (qmail 89931 invoked by alias); 23 Jan 2002 16:32:58 -0000
Received: from unknown (HELO postgresql.org) (64.49.215.8)
  by www.postgresql.org with SMTP; 23 Jan 2002 16:32:58 -0000
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NG9Tl75462
	for <pgsql-general@postgresql.org>; Wed, 23 Jan 2002 11:09:29 -0500 (EST)
	(envelope-from barry@xythos.com)
Received: from xythos.com (localhost.localdomain [127.0.0.1])
	by barry.xythos.com (8.11.6/8.11.6) with ESMTP id g0N1sGn24841;
	Tue, 22 Jan 2002 17:54:16 -0800
Message-ID: <3C4E17C8.8040909@xythos.com>
Date: Tue, 22 Jan 2002 17:54:16 -0800
From: Barry Lind <barry@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
X-Accept-Language: en-us
MIME-Version: 1.0
To: Nic Ferrier <nferrier@tapsellferrier.co.uk>
cc: Doug McNaught <doug@wireboard.com>, pgsql-general@postgresql.org
Subject: Re: [GENERAL] implemention of calls to stored procs.
References: <87sn8yx6xu.fsf@tf1.tapsellferrier.co.uk>	<m3r8oh6i1a.fsf@varsoon.denali.to> <87n0z5yjer.fsf@tf1.tapsellferrier.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR

Nic,

Check out http://www.rootshell.be/~hornyakl/download
This has the latest code for pl/pgj. The Java procedure language support 
that Laszlo Hornyak (hornyakl@users.sourceforge.net) has been working on 
for the last month or so.

thanks,
--Barry


Nic Ferrier wrote:

> Firstly, thanks for your responses... good to know I was thinking the
> right thing (and, yes, I was taking the process thing into account,
> tho' I didn't realise threads weren't used at all).
> 
> 
> Doug McNaught <doug@wireboard.com> writes:
> 
> 
>>Nic Ferrier <nferrier@tapsellferrier.co.uk> writes: 
>> 
>>
>>>I've been looking at the implementation of the procedural language  
>>>support code with a view to writing a java plugin (ie: something to 
>>>allow java classes to be used as stored procs). 
>>>
>> 
>>Someone else has been talking about this--check the archives from the 
>>last six months. 
>>
> 
> I couldn't find any reference but the archive searcher is broken right
> now and a manual search is not very reliable.
> 
> It's not terribly difficult to crack this actually... I was going to
> use GCJ as a platform for a base java class that could be used like a
> quick C stored proc.
> 
> I envisage having a natively implemented JDBC Connection passed to an
> init method in such a class.
> 
> 
> GCJ is perfect for this task because it has a native call interface,
> CNI, which is a seamless part of the class heirarchy.
> 
> Once I've got something working I'll drop a line here.
> 
> 
> 
> Nic
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 
> 



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-hackers-owner+M31158@postgresql.org Wed Oct 30 14:31:27 2002
Return-path: <pgsql-hackers-owner+M31158@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9UJVQU07194
	for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 14:31:26 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id 353C9476C3C; Wed, 30 Oct 2002 14:30:18 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with SMTP
	id D8787476C72; Wed, 30 Oct 2002 14:30:06 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id A8D81476C42
	for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP id 04987476C71
	for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9UJTvhR000820
	for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] PG functions in Java: maybe use gcj?
Date: Wed, 30 Oct 2002 14:29:57 -0500
Message-ID: <819.1036006197@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-Virus-Scanned: by AMaViS new-20020517
Status: OR

I had an interesting conversation today with Tom Tromey and Andrew Haley
of Red Hat about how to implement "pljava" for Postgres.  Rather than
futzing with an external JVM, their thought is to use gcj (gcc compiling
Java).  It sounds like this approach would mostly just work, modulo
needing to use a small amount of C++ code to call the defined APIs for
gcj.

This would not be a perfect solution: gcj isn't yet ported everywhere,
and it would probably not play nice on machines where the standard C
library isn't thread-safe.  But it seems a lot more within reach than
the approaches we've discussed in the past.

I'm not volunteering to try to do this, but I wanted to toss the idea
up in the air and see if anyone wants to try it.  Tom and Andrew
indicated they'd be willing to help out with advice etc for anyone
who wants to take on the project.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

From pgsql-hackers-owner+M31173@postgresql.org Wed Oct 30 22:51:48 2002
Return-path: <pgsql-hackers-owner+M31173@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9V3pkU27163
	for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 22:51:46 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id CC02B476CE9; Wed, 30 Oct 2002 22:51:42 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with SMTP
	id 30D78476087; Wed, 30 Oct 2002 22:51:25 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 49189475A1E
	for <pgsql-hackers@postgresql.org>; Wed, 30 Oct 2002 22:51:18 -0500 (EST)
Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by postgresql.org (Postfix) with ESMTP id B9C5B474E5C
	for <pgsql-hackers@postgresql.org>; Wed, 30 Oct 2002 22:51:17 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 1876OD-0006U9-00; Thu, 31 Oct 2002 03:53:01 +0000
Received: from h-66-166-17-184.snvacaid.covad.net ([66.166.17.184] helo=xythos.com)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 1876OC-0006Ty-00; Thu, 31 Oct 2002 03:53:00 +0000
Message-ID: <3DC0AA42.4000205@xythos.com>
Date: Wed, 30 Oct 2002 19:57:54 -0800
From: Barry Lind <blind@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
References: <819.1036006197@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Envelope-To: tgl@sss.pgh.pa.us,
	pgsql-hackers@postgreSQL.org
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-Virus-Scanned: by AMaViS new-20020517
Status: OR

I am not sure I follow.  Are you suggesting:

1)  create function takes java source and then calls gcj to compile it 
to native and build a .so from it that would get called at runtime?

or

2)  create function takes java source and just compiles to java .class 
files and the runtime invokes the gcj java interpreter.

or I guess you could do both at the same time.

In either case I am concerned about licensing issues.  gcj is not under 
a BSD style license.  Depending on what you need you are either dealing 
with regular GPL, LGPL, or LGPL with a special java exception.

I beleive (without giving it too much thought) that doing either 1 or 2 
above would end up linking GPL code into postgres.  This can be worked 
around by requiring the the necessary gcj libraries be installed 
separately and detected at configure time (like is done elsewhere).  But 
is does (I think) present a problem for commercial products that would 
like to redistribute postgres with pljava.


Another challenge here it that the java code is going to want to use the 
jdbc api when communicating with the database.  One difficulty here is 
getting jdbc to be part of the same transaction as the calling java 
function.  Such that if the java stored procedure selects or updates 
data it is doing it in the same transaction as the caller of the 
function.  Today the jdbc driver only knows how to communicate via the 
FE/BE protocol which will end up creating a new process and transaction. 
  The jdbc driver would need to not use the FE/BE protocol but instead 
probably use jni calls.

thanks,
--Barry


Tom Lane wrote:
> I had an interesting conversation today with Tom Tromey and Andrew Haley
> of Red Hat about how to implement "pljava" for Postgres.  Rather than
> futzing with an external JVM, their thought is to use gcj (gcc compiling
> Java).  It sounds like this approach would mostly just work, modulo
> needing to use a small amount of C++ code to call the defined APIs for
> gcj.
> 
> This would not be a perfect solution: gcj isn't yet ported everywhere,
> and it would probably not play nice on machines where the standard C
> library isn't thread-safe.  But it seems a lot more within reach than
> the approaches we've discussed in the past.
> 
> I'm not volunteering to try to do this, but I wanted to toss the idea
> up in the air and see if anyone wants to try it.  Tom and Andrew
> indicated they'd be willing to help out with advice etc for anyone
> who wants to take on the project.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 




---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

From pgsql-hackers-owner+M31175@postgresql.org Wed Oct 30 23:10:42 2002
Return-path: <pgsql-hackers-owner+M31175@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9V4AeU28809
	for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 23:10:41 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id 8C73B476AD5; Wed, 30 Oct 2002 23:10:33 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with SMTP
	id 2E9DC4761DF; Wed, 30 Oct 2002 23:10:31 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 1A441475A1E
	for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 23:10:25 -0500 (EST)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP id 7D378474E5C
	for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 23:10:24 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9V4AThR003716;
	Wed, 30 Oct 2002 23:10:29 -0500 (EST)
To: Barry Lind <blind@xythos.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj? 
In-Reply-To: <3DC0AA42.4000205@xythos.com> 
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com>
Comments: In-reply-to Barry Lind <blind@xythos.com>
	message dated "Wed, 30 Oct 2002 19:57:54 -0800"
Date: Wed, 30 Oct 2002 23:10:28 -0500
Message-ID: <3715.1036037428@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-Virus-Scanned: by AMaViS new-20020517
Status: OR

Barry Lind <blind@xythos.com> writes:
> I am not sure I follow.  Are you suggesting:
> 1)  create function takes java source and then calls gcj to compile it 
> to native and build a .so from it that would get called at runtime?
> or
> 2)  create function takes java source and just compiles to java .class 
> files and the runtime invokes the gcj java interpreter.
> or I guess you could do both at the same time.

The impression I had (after not looking very closely) was that you could
expect to compile to bytecodes on the fly and then run the gcj
interpreter.  But the .so alternative might be a good fallback if that
doesn't work.

> In either case I am concerned about licensing issues.  gcj is not under 
> a BSD style license.  Depending on what you need you are either dealing 
> with regular GPL, LGPL, or LGPL with a special java exception.
> I beleive (without giving it too much thought) that doing either 1 or 2 
> above would end up linking GPL code into postgres.  This can be worked 
> around by requiring the the necessary gcj libraries be installed 
> separately and detected at configure time (like is done elsewhere).  But 
> is does (I think) present a problem for commercial products that would 
> like to redistribute postgres with pljava.

Good point, but unless you want to build a BSD-license Java
implementation, there will never be a pljava that doesn't have different
licensing restrictions than PG itself does.  gcj is at least more free
than either Sun's or IBM's JVM ...

> Another challenge here it that the java code is going to want to use the 
> jdbc api when communicating with the database.

Yes.  I think we'd need a new implementation of jdbc that sits atop SPI
(invoked via jni I guess) rather than a FE/BE connection.  How well
layered is our jdbc code --- would this mean a large rewrite, or just
rolling in a new bottom layer?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

From pgsql-hackers-owner+M31202@postgresql.org Thu Oct 31 21:18:38 2002
Return-path: <pgsql-hackers-owner+M31202@postgresql.org>
Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gA12ILU00147
	for <pgman@candle.pha.pa.us>; Thu, 31 Oct 2002 21:18:37 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by west.navpoint.com (8.11.6/8.10.1) with ESMTP id g9VHv8h08054
	for <pgman@candle.pha.pa.us>; Thu, 31 Oct 2002 12:57:08 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id 5CA844768F1; Thu, 31 Oct 2002 12:54:18 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with SMTP
	id 973E1476060; Thu, 31 Oct 2002 12:54:11 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 9A45F47668B
	for <pgsql-hackers@postgresql.org>; Thu, 31 Oct 2002 12:54:05 -0500 (EST)
Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by postgresql.org (Postfix) with ESMTP id 0D7F5476684
	for <pgsql-hackers@postgresql.org>; Thu, 31 Oct 2002 12:54:05 -0500 (EST)
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 187JXx-0006Pc-00; Thu, 31 Oct 2002 17:55:57 +0000
Received: from sdsl-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 187JXx-0006PR-00; Thu, 31 Oct 2002 17:55:57 +0000
Message-ID: <3DC175F7.90901@xythos.com>
Date: Thu, 31 Oct 2002 10:27:03 -0800
From: Barry Lind <blind@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com> <3715.1036037428@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Envelope-To: tgl@sss.pgh.pa.us,
	pgsql-hackers@postgreSQL.org
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-Virus-Scanned: by AMaViS new-20020517
Status: OR



Tom Lane wrote:
> Barry Lind <blind@xythos.com> writes:
> 
>>In either case I am concerned about licensing issues.  gcj is not under 
>>a BSD style license.  Depending on what you need you are either dealing 
>>with regular GPL, LGPL, or LGPL with a special java exception.
>>I beleive (without giving it too much thought) that doing either 1 or 2 
>>above would end up linking GPL code into postgres.  This can be worked 
>>around by requiring the the necessary gcj libraries be installed 
>>separately and detected at configure time (like is done elsewhere).  But 
>>is does (I think) present a problem for commercial products that would 
>>like to redistribute postgres with pljava.
> 
> 
> Good point, but unless you want to build a BSD-license Java
> implementation, there will never be a pljava that doesn't have different
> licensing restrictions than PG itself does.  gcj is at least more free
> than either Sun's or IBM's JVM ...
> 

It depends on what you mean by more free.  An architecture that 
interacts with an external jvm would let you use any jvm (free ones as 
well as others).  From a licensing standpoint it is generally easy to 
redistribute a jvm or expect the user to have one installed (most java 
based products out there today do this).

However in the proposal here we are talking about requiring a specific 
jvm (gcj) and actually linking parts of it into postgres.  To the extent 
that GPL code is linked in the GPL extends to the entire code base.  As 
I said previously there are ways to work around this, but it becomes 
tricky.  Especially when a commercial product wants to bundle postgres 
and pljava.  That resulting bundle is probably entirely under the GPL 
and then any changes to it are also GPL.  So it could be the case that 
this company would be prevented from submitting improvements they made 
back to the core product because their improvements are GPLed as a 
result of pljava.

Now having said all that, I have been monitoring the progres of gcj for 
some time because I think there are very interesting possibilities.  And 
I am all for anyone who wants to look into it further and investigate 
the possiblities.  I just want to raise the licensing issue because it 
can cause problems and it is better to think about them up front than 
after the fact.

> 
>>Another challenge here it that the java code is going to want to use the 
>>jdbc api when communicating with the database.
> 
> 
> Yes.  I think we'd need a new implementation of jdbc that sits atop SPI
> (invoked via jni I guess) rather than a FE/BE connection.  How well
> layered is our jdbc code --- would this mean a large rewrite, or just
> rolling in a new bottom layer?
> 

It isn't as well layered as it could be, but it isn't too bad.  Overall 
it shouldn't be too much work, but not a little project either.  One 
area that isn't well layered is the assumption that the raw data from 
the server is in text format, since that is what the FE/BE protocol 
provides.  So all the conversion functions that convert to/from java 
datatypes do so in this format.  This assumption runs deep into the 
code.  As a first pass it would be easiest to get raw data from SPI 
convert to text and then convert to java datatypes instead of going 
directly from the internal SPI format directly to java datatypes.  This 
could be improved upon later.

> 			regards, tom lane
> 

thanks,
--Barry






---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

From pgsql-hackers-owner+M31223@postgresql.org Fri Nov  1 07:34:24 2002
Return-path: <pgsql-hackers-owner+M31223@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gA1CYKU23527
	for <pgman@candle.pha.pa.us>; Fri, 1 Nov 2002 07:34:21 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id C48C44762EE; Fri,  1 Nov 2002 07:34:13 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with SMTP
	id 1F69C475F34; Fri,  1 Nov 2002 07:34:11 -0500 (EST)
Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 06581474E53
	for <pgsql-hackers@postgresql.org>; Fri,  1 Nov 2002 07:34:07 -0500 (EST)
Received: from anchor-post-39.mail.demon.net (anchor-post-39.mail.demon.net [194.217.242.80])
	by postgresql.org (Postfix) with ESMTP id 7D34D474E44
	for <pgsql-hackers@postgresql.org>; Fri,  1 Nov 2002 07:34:06 -0500 (EST)
Received: from lfix.demon.co.uk ([158.152.59.127] helo=linda.lfix.co.uk)
	by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2)
	id 187b04-0002Pj-0U
	for pgsql-hackers@postgresql.org; Fri, 01 Nov 2002 12:34:08 +0000
Received: from localhost
	([127.0.0.1] helo=localhost.localdomain ident=olly)
	by linda.lfix.co.uk with esmtp (Exim 3.36 #1 (Debian))
	id 187b04-0007zb-00
	for <pgsql-hackers@postgresql.org>; Fri, 01 Nov 2002 12:34:08 +0000
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
From: Oliver Elphick <olly@lfix.co.uk>
To: pgsql-hackers@postgresql.org
In-Reply-To: <3DC175F7.90901@xythos.com>
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com>
	<3715.1036037428@sss.pgh.pa.us>  <3DC175F7.90901@xythos.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 01 Nov 2002 12:34:08 +0000
Message-ID: <1036154048.7925.73.camel@linda>
MIME-Version: 1.0
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
X-Virus-Scanned: by AMaViS new-20020517
Status: OR

On Thu, 2002-10-31 at 18:27, Barry Lind wrote:

> However in the proposal here we are talking about requiring a specific 
> jvm (gcj) and actually linking parts of it into postgres.  To the extent 
> that GPL code is linked in the GPL extends to the entire code base.  As 
> I said previously there are ways to work around this, but it becomes 
> tricky.  Especially when a commercial product wants to bundle postgres 
> and pljava.  That resulting bundle is probably entirely under the GPL 
> and then any changes to it are also GPL.  So it could be the case that 
> this company would be prevented from submitting improvements they made 
> back to the core product because their improvements are GPLed as a 
> result of pljava.

Nothing that company does can affect the licensing of PostgreSQL itself
- it doesn't belong to them, so they cannot change its licence.

Nothing in the GPL forces them to put GPL copyright on their own
alterations.

What they cannot do is to _distribute_ binary code that links to GPL
code while giving fewer rights to their distributees than they
themselves received with the GPL code, whether in respect of their own
code or the GPL code.  Therefore they would be required to make their
source changes available to anyone to whom they gave a binary, and they
would not be able to restrict the further distribution of those
changes.  They can contribute those changes to the project under
whatever licence they wish that is acceptable to the project.

Furthermore, gcj is part of the GNU compiler collection, like gcc, and
using it does not in itself cause code compiled under it to be subject
to the GPL.  Linking to its runtime library would normally cause that,
but the gcj-3.0 copyright contains the following text:

========================================================================
The libgcj library is licensed under the terms of the GNU General
Public License, with this special exception:

    As a special exception, if you link this library with other files
    to produce an executable, this library does not by itself cause
    the resulting executable to be covered by the GNU General Public
    License.  This exception does not however invalidate any other
    reasons why the executable file might be covered by the GNU
    General Public License.
========================================================================

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "But they that wait upon the LORD shall renew their 
      strength; they shall mount up with wings as eagles; 
      they shall run, and not be weary; and they shall walk,
      and not faint."            Isaiah 40:31 


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)