lixa-general Mailing List for lixa
LIXA, LIbre XA, is a free and open source XA transaction manager
Brought to you by:
tiian
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
(3) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: <lix...@li...> - 2020-10-22 20:21:59
|
Dear Lawrence,I'm replying you through LIXA mailing list because I like to keep this type of discussion in the public space. Here is my review about your proposed changes: Structural notes: 1. don't create a couple of new files (tx_lixa.c/h) for your extension, they can be put directly in tx.c/tx.h by the way, there are already some extensions contributed by Globetom some years ago like tx_join, tx_resume, etc.. Interface notes: 1. I don't like the idea of overloading the original tx_open and creating a "black swan" function named tx_open_something() I don't like the idea of passing an array of structs to the function just for configuration: in the end, the developer would have to allocate the array static/dynamic populate the array because the source information probably comes from a different place pass the array to the function call tx_open_something() destroy the array that is not anymore useful to stay aligned with the original TX design, I prefer an interface splitted in two parts: tx_add_resource_manager(...); tx_open(); tx_add_resource_manager() will be coherent with similar standard functions like tx_set_transaction_control(), tx_set_transaction_timeout(), etc... following the above approach, the resulting application code will be: tx_add_resource_manager(...); /* any number of times, depending on the use case */ tx_open(); tx_add_resource_manager(...) will save the data in the thread context (client_status_t) tx_open() will pick-up the additional resource managers from the thread context (client_status_t), if any after all the above, the signature of tx_add_resource_manager() becomes: extern int tx_add_resource_manager(const char *profile, const char *name, const char *switch_file, const char *xa_open_info, const char *xa_close_info); the return code must be in the set of TX standard return codes, see file tx.h. Examples: TX_OK, TX_ERROR. It must *not* be a LIXA_RC_something Warnings: the final destination is a struct of type rsrmgr_config_s you have to use proper functions to duplicate to xmlChar destinations for name and switch_file, see http://xmlsoft.org/html/libxml-xmlstring.html#xmlCharStrdup you have to pay attention xa_open_info and xa_close_info are defined as char[MAXINFOSIZE] by the XA specification as you proposed with tx_open_lixa(), don't put logic in tx.c because it's just an adapter: real logic must be in a new function lixa_tx_add_resource_manager in file lixa_tx.c 2. the same principle applies to tx_begin_lixa(): at the end of the day, the application want to specify a prefix that many times will stay stable in a context I prefer an interface splitted in two parts and aligned with TX original design: tx_set_gtrid_prefix(); tx_begin(); even in this case, tx_set_gtrid_prefix() will store the prefix in the context of the thread and can be reused by as many tx_begin() calls as necessary, without the burden to scatter the prefix in different parts of the application program. That's a typical info coming from the configuration, while tx_begin() is a function you typically call from a piece of business logic. the signature becomes: extern int tx_set_gtrid_prefix(const char *gtrid_prefix, long gtrid_prefix_length); as above the return code must be TX_* as described in file tx.h Warnings: the XA specification REQUIRES the XID to be a BINARY arrays, an array of octets, NOT a string of characters, even if it's implemented using "char" type instead of something like "unsigned char" or "byte_t" This is why LIXA traces it in exadecimal format; don't mind PostgreSQL uses the ASCII subset, the XA specification is much more generic Once you have the gtrid_prefix and gtrid_prefix_length in the thread context (client_status_t) you must intercept XID generation and override the first gtrid_prefix_length byte with memcpy... PAY ATTENTION gtrid_prefix_length MUST NOT exceed the "gtrid_length" so the algorith should be: - generate the XID with the current algorithm - if(gtrid_prefix_length > 0) replace the first N bytes where N = min(XID.gtrid_length, gtrid_prefix_length) WARNING: tainting the "bqual" part of the XID can produce UNEXPECTED behaviors 3. with all the above, creating the equivalent COBOL TX interface for tx_add_resource_manager() and tx_set_gtrid_prefix() will be quite straighforward if someone asks for it 4. the new functions must be documented in the LIXA reference manual (docbook format) like these ones https://www.tiian.org/lixa/manuals/html/ch07.html 5. the new functions should carry at least one sample program to put in doc/examples directory 6. the new functions must be tested with dedicated test cases tx_....at; from the description in the email you are implementing a non trivial use case: ALL THE POSSIBLE CODE PATHS MUST BE COVERED BY TEST CASES AND DOUBLE CHECKED FOR MEMORY LEAKS Coding style notes: 1. XA and TX standard have their own coding style, CaMeLiZaTion is never used in the LIXA C source code and not used by XA and TX specification: rmNname --> rm_name rmSwitchFile --> rm_switch_file and so on... 2. don't put "_" in front of a type or a variable, that's typically dedicated to internal special stuff like __GNUC__ and others 3. LIXA_TRACE has a strict format: - the message prefix is the name of the function followed by a colon like "lixa_tx_open: " otherwise, DIFFICULT to understand where the message comes from - strings are typically surronded by single quotes like '%s' to figure they are values and not constants when the trace must be read - numbers are typically wrote without quotes like %d (it's unlikely there are constant numbers in trace messages) Syntax notes: 1. Doxygen autodocumentation requires strict match between the name of the parameter in the functon declaration and the same name in the documentation comment 2. Doxygen comments must stay only in .h files not in both .h and .c 3. When a function throw the same "exception" several times, it MUST be enumerated, otherwise NO way to understand the exception point from the trace file. Example: bad if (NULL == (rsrmgr = g_try_malloc( sizeof(struct rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR); if (NULL == (act_rsrmgr = g_try_malloc( sizeof(struct act_rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR); good if (NULL == (rsrmgr = g_try_malloc( sizeof(struct rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR1); if (NULL == (act_rsrmgr = g_try_malloc( sizeof(struct act_rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR2); Process notes: 1. as soon as your code reach enough maturity, fork the master trunk of the source code on github and merge from the master as frequently as possible before creating the pull request 2. I'm currently working on version 1.9.3; it basically contains refinements like CentOS 8 support and it could be a good candidate to host your extension Alternatively, a new 1.11.0 could be created to underline the new capabilities 3. sanitize the code using valgrind, the automatic testing suite is already instrumented, just activate the env var SERVER_CHECK_TYPE=memory (see script functions tests/lixa_test_functions.sh) The critical point of your extension is manipulating the list of resource managers defined in the thread context: it's very easy to introduce memory leaks in that piece of code. In the past it required several fixes. The other change tx_set_gtrid_prefix() is easier and safer to implement. Hoping it will help.Kind RegardsCh.F. ----- Messaggio inoltrato -----Inviato: martedì 20 ottobre 2020, 10:07:10 CESTOggetto: LIXA changes for Resource Manager definitions Dear Christian, I attach some updated files for your comments. These are based on v1.9.0. I have added a new function tx_open_lixa() which has parameters to specify (a) an optional profile name and (b) a list of Resource Managers. · The profile name acts like, and overrides, the LIXA_PROFILE environment variable. This is done by passing the profile from tx_open_lixa() to client_config(). · If specified, the list of RMs is then added to the RMs loaded from the profile. These are added as ‘dynamically-defined’ RMs. · The RM list entry (see tx_lixa.h) contains the same as in the RM definition in lixac_conf.xml: Name, SwitchFile, OpenInfo and CloseInfo. · If Name is specified, it must exist as a definition in lixac_conf, and from that definition the switch_file, open_info and close_info can be overridden if desired. The act_rsrmgr is created and linked to the existing rsrmgr. · If no name is specified (NULL), then the other 3 parameters must be specified. An ‘anonymous’ rsrmgr structure is created, and the act_rsrmgr links to that. So the result is similar to the enlist function in xta. The tx_close() function then removes the dynamically-defined act_rsrmgr objects, and any anonymous rsrmgr objects. The main code for this has been added to lixa_tx_open() in lixa_tx.c, which now has profile and RM list parameters. You can search for “Wilkinson” in this file to find what I have added, but I will copy the important parts at the bottom of this email. The tx_lixa.h file also includes a new tx_begin function with a GTrid parameter, but I have not started on that yet. I still need to do a check for leaks and other errors, but I would like to verify that I haven’t done anything stupid with my changes and that you are happy with function names etc. Best regards, Lawrence ypedef struct _RMspec { const char* rmName; /* Must be specified */ const char* rmSwitchFile; /* Optional if rmName is in profile */ const char* rmOpenInfo; /* ditto */ const char* rmCloseInfo; /* ditto */ } RMspec; extern int tx_open_lixa( const char* profile, int numRM, const RMspec *listRM ); int lixa_tx_open(int *txrc, int mmode, const char* profile, int numRM, const RMspec *listRM) (numRM and listRM are the user’s RM list) /* Add user-supplied RMs */ int iRM; if (NULL != listRM) { for (iRM = 0; iRM < numRM; iRM++) { struct rsrmgr_config_s *rsrmgr = NULL; // Meant for Xml, but we use it here struct act_rsrmgr_config_s *act_rsrmgr = NULL; const RMspec *currentRM = &listRM[iRM]; /* allocate a new record for the Resource Manager description */ if (NULL == (rsrmgr = g_try_malloc( sizeof(struct rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR); if (NULL == (act_rsrmgr = g_try_malloc( sizeof(struct act_rsrmgr_config_s)))) THROW(G_TRY_MALLOC_ERROR); /* Populate the rsrmgr_config_s from the RM in the list */ /* First try to find an existing rsrmgr definition */ if (currentRM->rmName) { rsrmgr->name = NULL; /* Flag we have not found it yet */ /* Loop through specified rsrmgrs */ int i; for (i = 0; i < global_ccc.rsrmgrs->len; ++i) { struct rsrmgr_config_s *templateRsrmgr = (struct rsrmgr_config_s *) g_ptr_array_index(global_ccc.rsrmgrs, i); if (strcmp((char*)templateRsrmgr->name, currentRM->rmName) == 0) { /* Found it - duplicate it and use it as a template */ if (NULL == (rsrmgr->name = (xmlChar*)strdup( currentRM->rmName ))) { g_free(rsrmgr); THROW(STRDUP_ERROR); } if (currentRM->rmSwitchFile) { if (NULL == (rsrmgr->switch_file = (xmlChar*)strdup( currentRM->rmSwitchFile ))) { g_free(rsrmgr); THROW(STRDUP_ERROR); } } else { if (NULL == (rsrmgr->switch_file = xmlStrdup( templateRsrmgr->switch_file ))) { g_free(rsrmgr); THROW(XML_STRDUP_ERROR); } } if (currentRM->rmOpenInfo) { strncpy( rsrmgr->xa_open_info, currentRM->rmOpenInfo, sizeof(rsrmgr->xa_open_info) ); } else { rsrmgr->xa_open_info[0] = 0; } if (currentRM->rmCloseInfo) { strncpy( rsrmgr->xa_close_info, currentRM->rmCloseInfo, sizeof(rsrmgr->xa_close_info) ); } else { rsrmgr->xa_close_info[0] = 0; } LIXA_TRACE(("RM %s (%s) created\n", rsrmgr->name, rsrmgr->xa_open_info)); break; } } if (rsrmgr->name == NULL) { /* Not found - error */ LIXA_TRACE(("RM %s not defined\n", currentRM->rmName)); THROW(INVALID_RM_ERROR); } } else { rsrmgr->name = NULL; /* Anonymous */ rsrmgr->switch_file = (xmlChar*)strdup( currentRM->rmSwitchFile ); strncpy( rsrmgr->xa_open_info, currentRM->rmOpenInfo, sizeof(rsrmgr->xa_open_info) ); strncpy( rsrmgr->xa_close_info, currentRM->rmCloseInfo, sizeof(rsrmgr->xa_close_info) ); LIXA_TRACE(("RM %s created", rsrmgr->switch_file)); } act_rsrmgr->generic = rsrmgr; act_rsrmgr->module = NULL; memset(&act_rsrmgr->lixa_iface, 0, sizeof(lixa_iface_t)); act_rsrmgr->dynamically_defined = TRUE; /* load the switch file for the resource manager, * set it as "dynamically defined" */ if (LIXA_RC_OK != (ret_cod = client_config_load_switch_file( act_rsrmgr, TRUE))) THROW(CLIENT_CONFIG_LOAD_SWITCH_FILE_ERROR); client_config_display_rsrmgr( act_rsrmgr ); /* append the resource manager to the list of actual configured resource managers */ client_config_append_rsrmgr(&global_ccc, rsrmgr, act_rsrmgr); } } lixa_tx_close() /* remove dynamically added RMs */ int i; for (i = 0; i < global_ccc.actconf.rsrmgrs->len; i++) { struct act_rsrmgr_config_s *act_rsrmgr = (struct act_rsrmgr_config_s *) g_ptr_array_index(global_ccc.rsrmgrs, i); if (act_rsrmgr->dynamically_defined) { ret_cod = client_config_unload_switch_file( act_rsrmgr); if (NULL == act_rsrmgr->generic->name) { // Anonymous RM - remove it g_ptr_array_remove(global_ccc.rsrmgrs, act_rsrmgr->generic); g_free(act_rsrmgr->generic); } g_ptr_array_remove_index(global_ccc.actconf.rsrmgrs, i); g_free(act_rsrmgr); } } int client_config(client_config_coll_t *ccc, int global_config, const char* profile) (profile is the parameter from tx_open_lixa()) if (profile) { LIXA_TRACE(("client_config: using transactional profile '%s' for " "subsequent operations\n", profile)); if (NULL == (ccc->profile = g_strdup(profile))) THROW(G_STRDUP_ERROR); } else if (NULL == (tmp_str = getenv(LIXA_PROFILE_ENV_VAR))) { /* use empty string instead of NULL to avoid allocation issues */ ccc->profile = tmp_str; LIXA_TRACE(("client_config: '%s' environment variable not found, " "using default profile for this client\n", LIXA_PROFILE_ENV_VAR)); } else { LIXA_TRACE(("client_config: using transactional profile '%s' for " "subsequent operations\n", tmp_str)); if (NULL == (ccc->profile = g_strdup(tmp_str))) THROW(G_STRDUP_ERROR); } _______________________________________ Lawrence Wilkinson Senior Developer LzLabs GmbH Richtiarkade 16 CH-8304 Wallisellen Switzerland web www.lzlabs.com |
|
From: <lix...@li...> - 2020-10-08 10:58:28
|
Thinking about the question, there are some additional caveats to take into consideration.
Supposing you are using XTA for C, not XTA for Java, there are two different types of XA resources: "native" and "acquired".
Acquired resources, like for example MySQL (or MariaDB) and PostgreSQL, do not provide a real XA standard interface, but some hooks to implement an "XA like" behaviour.For both xta_postgresql_xa_resource_t and xta_mysql_xa_resource_t, the reasoning of my previous message applies.
Native resources, like for example Oracle Database, provide a real XA standard interface and don't require a specific "class" for every implementation: a single one named xta_native_xa_resource_t is sufficient.At this point the question: can I pass the reference of xta_native_xa_resource_t from one thread to another is constrained by the underlying XA implementation of the software vendor. It's not necessarily guarantee it works, but there's a "but": the XA standard provides a technique named "suspend/resume" that's XTA implements by mean of xta_transaction_suspend and xta_transaction_resume. It works even for different processes, not only for different threads, as in example example_xta_macc01.c
To make a long story short:
- for "acquired" XA resources it should work without further complexity
- for "native" XA resources, in the event it does not work due to the software vendor implementation, you should be able to get the result with the "suspend/resume" mechanism.
Kind RegardsCh.F.
---
Il mercoledì 7 ottobre 2020, 08:09:54 CEST, lixa-general--- via Lixa-general <lix...@li...> ha scritto:
Dear Rowland,it's exactly as you described.Just pay attention that with XTA, a single thread at a time can manage a transaction: the methods/functions that manage the references are re-entrant, but not thread safe. In other terms, if two threads must deal with the same references, it's your responsibility to synchronize them and avoid that two threads use the same references in parallel.
Kind RegardsCh.F.
---
Il mercoledì 7 ottobre 2020, 05:02:42 CEST, lix...@li... <lix...@li...> ha scritto:
I have been working to integrate LIXA into a transaction monitor for the Pony programming language. My original plan was to use the TX interface, but I believe that this interface is limited to calling tx_open() and tx_close() on the same thread. This requirement would greatly reduce the flexibility and power of my transaction monitor, and would not take much advantage of the Pony actor model.
I think that if I instead use the XTA interface, I will no longer face this limitation, and as long as I pass transaction manager and transaction references around in a safe manner, I will be able to support as many threads as needed.
Please confirm if my understanding is correct.
LIXA looks like a really nice piece of work. I am really looking forward to digging more deeply into it.
--
Rowland E. SmithP: (862) 260-4163M: (201) 396-3842
_______________________________________________
Lixa-general mailing list
Lix...@li...
https://lists.sourceforge.net/lists/listinfo/lixa-general
_______________________________________________
Lixa-general mailing list
Lix...@li...
https://lists.sourceforge.net/lists/listinfo/lixa-general
|
|
From: <lix...@li...> - 2020-10-07 06:09:47
|
Dear Rowland,it's exactly as you described.Just pay attention that with XTA, a single thread at a time can manage a transaction: the methods/functions that manage the references are re-entrant, but not thread safe. In other terms, if two threads must deal with the same references, it's your responsibility to synchronize them and avoid that two threads use the same references in parallel.
Kind RegardsCh.F.
---
Il mercoledì 7 ottobre 2020, 05:02:42 CEST, lix...@li... <lix...@li...> ha scritto:
I have been working to integrate LIXA into a transaction monitor for the Pony programming language. My original plan was to use the TX interface, but I believe that this interface is limited to calling tx_open() and tx_close() on the same thread. This requirement would greatly reduce the flexibility and power of my transaction monitor, and would not take much advantage of the Pony actor model.
I think that if I instead use the XTA interface, I will no longer face this limitation, and as long as I pass transaction manager and transaction references around in a safe manner, I will be able to support as many threads as needed.
Please confirm if my understanding is correct.
LIXA looks like a really nice piece of work. I am really looking forward to digging more deeply into it.
--
Rowland E. SmithP: (862) 260-4163M: (201) 396-3842
_______________________________________________
Lixa-general mailing list
Lix...@li...
https://lists.sourceforge.net/lists/listinfo/lixa-general
|
|
From: <lix...@li...> - 2020-10-07 03:02:40
|
I have been working to integrate LIXA into a transaction monitor for the Pony programming language. My original plan was to use the TX interface, but I believe that this interface is limited to calling tx_open() and tx_close() on the same thread. This requirement would greatly reduce the flexibility and power of my transaction monitor, and would not take much advantage of the Pony actor model. I think that if I instead use the XTA interface, I will no longer face this limitation, and as long as I pass transaction manager and transaction references around in a safe manner, I will be able to support as many threads as needed. Please confirm if my understanding is correct. LIXA looks like a really nice piece of work. I am really looking forward to digging more deeply into it. -- *Rowland E. Smith* P: (862) 260-4163 M: (201) 396-3842 |
|
From: <lix...@li...> - 2019-01-20 13:50:10
|
I'm proud to announce the new LIXA release: 1.7.2It provides full support of XTA for Java.With this release, XTA support the four most relevant languages (Java, C, Python, C++) according to TIOBE Index | TIOBE - The Software Quality Company | | | | | | | | | | | TIOBE Index | TIOBE - The Software Quality Company The TIOBE Programming Community index is an indicator of the popularity of programming languages. | | | Enjoy LIXA!Ch.F. --------------------------------------------------------------------------------------Products are not about features, but about how to manage them. |
|
From: <lix...@li...> - 2017-06-02 20:34:40
|
On Fri, Jun 2, 2017 at 3:06 PM, <lix...@li...> wrote: Dear Lixa developers, We have been thinking about using Lixa in one of our projects. I therefore have two questions: * Do you have any Lixa performance numbers? I.e., what is the performance overhead with Lixa when compared to not using Lixa? You must have decided to use Lixa for a reason, how can you live without a Transaction Manager (TM)? So in effect what you need is a comparison of Lixa with any other TM. I am not aware of any such published comparison though. LIXA is based on a distributed architecture: at least network latency will slow down the performance in comparison with a local TM like Oracle Tuxedo or IBM TXSeries. On the other hand, it supports some modern use cases like TC TX added by www.globetom.com * Doing a best estimate guess: what is the amount of code required to support SQLite in addition to Mysql/Psql? Does SQLite support prepared transactions i.e. two phase commit? If not then it is a case of adding a non-XA complaint resource manager to the transaction manager, which is not the usual case. In order to add a resource manager to a transaction manager the developer has to provide an shared library implementing the XA interface functions. Take a look to the content of src/client/switch/mysql or src/client/switch/ to figure out how much work is needed.As pointed out by Abbas, the Resource Manager that you want to integrate must provide some a minimal set of functions that you can wrap and extend. Best RegardsCh.F. |
|
From: <lix...@li...> - 2017-06-02 11:28:23
|
On Fri, Jun 2, 2017 at 3:06 PM, <lix...@li...> wrote: > Dear Lixa developers, > > We have been thinking about using Lixa in one of our projects. I > therefore have two questions: > > * Do you have any Lixa performance numbers? I.e., what is the > performance overhead with Lixa when compared to not using Lixa? > You must have decided to use Lixa for a reason, how can you live without a Transaction Manager (TM)? So in effect what you need is a comparison of Lixa with any other TM. I am not aware of any such published comparison though. > > * Doing a best estimate guess: what is the amount of code required to > support SQLite in addition to Mysql/Psql? > Does SQLite support prepared transactions i.e. two phase commit? If not then it is a case of adding a non-XA complaint resource manager to the transaction manager, which is not the usual case. In order to add a resource manager to a transaction manager the developer has to provide an shared library implementing the XA interface functions. > > Thanks a lot! > Florian > > > -- > Dr. Florian Kelbert > Department of Computing > Imperial College London > www.doc.ic.ac.uk/~fkelbert/ > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Lixa-general mailing list > Lix...@li... > https://lists.sourceforge.net/lists/listinfo/lixa-general > > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m <http://www.enterprisedb.com/> *Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers <http://www.enterprisedb.com/resources-community> and more <http://www.enterprisedb.com/resources-community> |
|
From: <lix...@li...> - 2017-06-02 10:06:41
|
Dear Lixa developers, We have been thinking about using Lixa in one of our projects. I therefore have two questions: * Do you have any Lixa performance numbers? I.e., what is the performance overhead with Lixa when compared to not using Lixa? * Doing a best estimate guess: what is the amount of code required to support SQLite in addition to Mysql/Psql? Thanks a lot! Florian -- Dr. Florian Kelbert Department of Computing Imperial College London www.doc.ic.ac.uk/~fkelbert/ |
|
From: <lix...@li...> - 2017-01-21 22:05:46
|
Dear All,with LIXA version 1.1.1, I have released: - support for Gnu COBOL 1.1 (and above, I suppose) - support for Oracle Pro*COBOL (and Oracle Pro*C) - some examples with Gnu COBOL, PostgreSQL, Oracle and PostgreSQL & Oracle together. In the next developments I will address different topics, but if someone provides further Gnu COBOL support it will be welcome. CheersCh.F. |
|
From: <lix...@li...> - 2017-01-19 22:52:39
|
Hi Mine,I've just released the first running example with GnuCOBOL (1.1) and Oracle Pro*COBOL 12.1: https://github.com/tiian/lixa/commit/54d0a9b0c5f063e80637c9d448a7bdab16deb4cbI'm quite proud about it because I'm not a COBOL programmer!Maybe the examples are quite trivial but they can be a starting point for real COBOL developers.What do you think about trying to contribute the project adding support for OCESQL?I have to switch to some new complex and exciting stuff related to LIXA.RegardsCh.F. ----------------------------- Products come & go Culture stays Da: "lix...@li..." <lix...@li...> A: lix...@li... Inviato: Domenica 18 Dicembre 2016 19:10 Oggetto: Re: [LIXA-general] Removing support for Ubuntu 10.04 Hello, Christian opensource COBOL https://github.com/opensourcecobol/opensource-cobol and OCESQL https://github.com/tollofsen/ocesql It is works fine with PostgreSQL. OCESQL is like Pro*COBOL. https://www.csee.umbc.edu//portal/help/oracle8.bak/server803/A54659_01/toc.htm Are you interested in this combination? Regards Mine On 2016/12/19 2:04, lix...@li... wrote: > Due to OpenCobol 1.0, that's not enough to go on with PostgreSQL, I have > switched to Ubuntu 14.04 as the bare minimum version. > Maybe, the next LIXA version will be targeted to Ubuntu 14.04 with some > backward compatibility for non COBOL application programs, > Regards > Ch.F. > > > > ------------------------------------------------------------------------ > *Da:* "lix...@li..." > <lix...@li...> > *A:* "lix...@li..." > <lix...@li...> > *Inviato:* Sabato 10 Dicembre 2016 18:58 > *Oggetto:* [LIXA-general] Removing support for Ubuntu 10.04 > > Dear LIXA users, > does anyone mind if I jump from Ubuntu 10.04 to Ubuntu 12.04 as the > lowest supported operating system version? > I'm going to support COBOL (GNU COBOL) for TX demarcation specification > and I'm not anymore able to fetch packages for the old Ubuntu 12.04. > This could be the right time to remove some glib deprecated stuff too. > Please send me a feedback if you still need Ubuntu 10.04 support. > > Regards > Ch.F. > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/xeonphi > _______________________________________________ > Lixa-general mailing list > Lix...@li... > <mailto:Lix...@li...> > https://lists.sourceforge.net/lists/listinfo/lixa-general > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Lixa-general mailing list > Lix...@li... > https://lists.sourceforge.net/lists/listinfo/lixa-general > -- 峰松 浩樹 有限会社ランカードコム 850-0057 長崎県長崎市大黒町11番13号 TEL: 095-840-0021 FAX: 095-895-7869 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Lixa-general mailing list Lix...@li... https://lists.sourceforge.net/lists/listinfo/lixa-general |
|
From: <lix...@li...> - 2017-01-08 22:10:02
|
Dear All,I've just released 1.1.0, the first release that supports GnuCOBOL: https://sourceforge.net/projects/lixa/files/lixa/testing/ Here's the first tested and supported configuration:Ubuntu 14.04, GnuCOBOL 1.1, PostgreSQL 9.3Further configurations will be developed in the near future. RegardsCh.F. Da: "lix...@li..." <lix...@li...> A: "ope...@li..." <ope...@li...>; "lix...@li..." <lix...@li...> Inviato: Venerdì 23 Dicembre 2016 23:10 Oggetto: [LIXA-general] LIXA initial support for GNU COBOL I'm proud to announce that LIXA has started to support GNU COBOL.The first two running examples (Ubuntu 14.04 is the current base version) are available here: https://github.com/tiian/lixa/tree/master/doc/examples/cobolhttps://sourceforge.net/p/lixa/git/ci/master/tree/doc/examples/cobol/ The first supported XA compliant Resource Manager is PostgreSQL; the "direct" approach as explained here: http://open-cobol.sourceforge.net/faq/#direct-postgresql-sample has been used. More Resource Managers and more examples will follow. LIXA brief overview. LIXA is an XA compliant Transaction Manager: it strictly adheres to XA specification (https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=c193) and it provides a standard TX (Transaction Demarcation) Specification API (https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=11221) to allow developers in building two phase commit transactions. TX API is a double faced API: there's a C version and a COBOL version. Please use LIXA "Open Discussion" forum https://sourceforge.net/p/lixa/discussion/934465/to suggest your preferred/desired resource managers and all the hints that can help. Regards,Ch.F. ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Lixa-general mailing list Lix...@li... https://lists.sourceforge.net/lists/listinfo/lixa-general |
|
From: <lix...@li...> - 2016-12-23 22:11:09
|
I'm proud to announce that LIXA has started to support GNU COBOL.The first two running examples (Ubuntu 14.04 is the current base version) are available here: https://github.com/tiian/lixa/tree/master/doc/examples/cobolhttps://sourceforge.net/p/lixa/git/ci/master/tree/doc/examples/cobol/ The first supported XA compliant Resource Manager is PostgreSQL; the "direct" approach as explained here: http://open-cobol.sourceforge.net/faq/#direct-postgresql-sample has been used. More Resource Managers and more examples will follow. LIXA brief overview. LIXA is an XA compliant Transaction Manager: it strictly adheres to XA specification (https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=c193) and it provides a standard TX (Transaction Demarcation) Specification API (https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=11221) to allow developers in building two phase commit transactions. TX API is a double faced API: there's a C version and a COBOL version. Please use LIXA "Open Discussion" forum https://sourceforge.net/p/lixa/discussion/934465/to suggest your preferred/desired resource managers and all the hints that can help. Regards,Ch.F. |
|
From: <lix...@li...> - 2016-12-18 20:37:58
|
Dear Mine,I'm interested in OCESQL and I will try to implement a support for LIXA in future.At this time I'm working on "Direct PostgreSQL" as it's explained here: http://open-cobol.sourceforge.net/faq/#direct-postgresql-sampleThanks for the pointers.RegardsCh.F. ----------------------------- Products come & go Culture stays Da: "lix...@li..." <lix...@li...> A: lix...@li... Inviato: Domenica 18 Dicembre 2016 19:10 Oggetto: Re: [LIXA-general] Removing support for Ubuntu 10.04 Hello, Christian opensource COBOL https://github.com/opensourcecobol/opensource-cobol and OCESQL https://github.com/tollofsen/ocesql It is works fine with PostgreSQL. OCESQL is like Pro*COBOL. https://www.csee.umbc.edu//portal/help/oracle8.bak/server803/A54659_01/toc.htm Are you interested in this combination? Regards Mine On 2016/12/19 2:04, lix...@li... wrote: > Due to OpenCobol 1.0, that's not enough to go on with PostgreSQL, I have > switched to Ubuntu 14.04 as the bare minimum version. > Maybe, the next LIXA version will be targeted to Ubuntu 14.04 with some > backward compatibility for non COBOL application programs, > Regards > Ch.F. > > > > ------------------------------------------------------------------------ > *Da:* "lix...@li..." > <lix...@li...> > *A:* "lix...@li..." > <lix...@li...> > *Inviato:* Sabato 10 Dicembre 2016 18:58 > *Oggetto:* [LIXA-general] Removing support for Ubuntu 10.04 > > Dear LIXA users, > does anyone mind if I jump from Ubuntu 10.04 to Ubuntu 12.04 as the > lowest supported operating system version? > I'm going to support COBOL (GNU COBOL) for TX demarcation specification > and I'm not anymore able to fetch packages for the old Ubuntu 12.04. > This could be the right time to remove some glib deprecated stuff too. > Please send me a feedback if you still need Ubuntu 10.04 support. > > Regards > Ch.F. > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/xeonphi > _______________________________________________ > Lixa-general mailing list > Lix...@li... > <mailto:Lix...@li...> > https://lists.sourceforge.net/lists/listinfo/lixa-general > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Lixa-general mailing list > Lix...@li... > https://lists.sourceforge.net/lists/listinfo/lixa-general > -- 峰松 浩樹 有限会社ランカードコム 850-0057 長崎県長崎市大黒町11番13号 TEL: 095-840-0021 FAX: 095-895-7869 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Lixa-general mailing list Lix...@li... https://lists.sourceforge.net/lists/listinfo/lixa-general |
|
From: <lix...@li...> - 2016-12-18 18:29:18
|
Hello, Christian opensource COBOL https://github.com/opensourcecobol/opensource-cobol and OCESQL https://github.com/tollofsen/ocesql It is works fine with PostgreSQL. OCESQL is like Pro*COBOL. https://www.csee.umbc.edu//portal/help/oracle8.bak/server803/A54659_01/toc.htm Are you interested in this combination? Regards Mine On 2016/12/19 2:04, lix...@li... wrote: > Due to OpenCobol 1.0, that's not enough to go on with PostgreSQL, I have > switched to Ubuntu 14.04 as the bare minimum version. > Maybe, the next LIXA version will be targeted to Ubuntu 14.04 with some > backward compatibility for non COBOL application programs, > Regards > Ch.F. > > > > ------------------------------------------------------------------------ > *Da:* "lix...@li..." > <lix...@li...> > *A:* "lix...@li..." > <lix...@li...> > *Inviato:* Sabato 10 Dicembre 2016 18:58 > *Oggetto:* [LIXA-general] Removing support for Ubuntu 10.04 > > Dear LIXA users, > does anyone mind if I jump from Ubuntu 10.04 to Ubuntu 12.04 as the > lowest supported operating system version? > I'm going to support COBOL (GNU COBOL) for TX demarcation specification > and I'm not anymore able to fetch packages for the old Ubuntu 12.04. > This could be the right time to remove some glib deprecated stuff too. > Please send me a feedback if you still need Ubuntu 10.04 support. > > Regards > Ch.F. > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/xeonphi > _______________________________________________ > Lixa-general mailing list > Lix...@li... > <mailto:Lix...@li...> > https://lists.sourceforge.net/lists/listinfo/lixa-general > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Lixa-general mailing list > Lix...@li... > https://lists.sourceforge.net/lists/listinfo/lixa-general > -- 峰松 浩樹 有限会社ランカードコム 850-0057 長崎県長崎市大黒町11番13号 TEL: 095-840-0021 FAX: 095-895-7869 |
|
From: <lix...@li...> - 2016-12-18 17:04:17
|
Due to OpenCobol 1.0, that's not enough to go on with PostgreSQL, I have switched to Ubuntu 14.04 as the bare minimum version.Maybe, the next LIXA version will be targeted to Ubuntu 14.04 with some backward compatibility for non COBOL application programs,RegardsCh.F.
Da: "lix...@li..." <lix...@li...>
A: "lix...@li..." <lix...@li...>
Inviato: Sabato 10 Dicembre 2016 18:58
Oggetto: [LIXA-general] Removing support for Ubuntu 10.04
Dear LIXA users,does anyone mind if I jump from Ubuntu 10.04 to Ubuntu 12.04 as the lowest supported operating system version?I'm going to support COBOL (GNU COBOL) for TX demarcation specification and I'm not anymore able to fetch packages for the old Ubuntu 12.04.This could be the right time to remove some glib deprecated stuff too.Please send me a feedback if you still need Ubuntu 10.04 support.
RegardsCh.F.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Lixa-general mailing list
Lix...@li...
https://lists.sourceforge.net/lists/listinfo/lixa-general
|
|
From: <lix...@li...> - 2016-12-10 17:58:23
|
Dear LIXA users,does anyone mind if I jump from Ubuntu 10.04 to Ubuntu 12.04 as the lowest supported operating system version?I'm going to support COBOL (GNU COBOL) for TX demarcation specification and I'm not anymore able to fetch packages for the old Ubuntu 12.04.This could be the right time to remove some glib deprecated stuff too.Please send me a feedback if you still need Ubuntu 10.04 support. RegardsCh.F. |
|
From: <lix...@li...> - 2014-10-13 20:09:42
|
Dear Muhammad, I have no idea about the architecture behind mysqlnd_ms XA transaction support, but I can give you some details related to LIXA & PHP. LIXA is a distributed transaction manager and, for sure, it introduces some delay due to the TCP/IP communication latency. LIXA supports different resource managers, it's not specific to MySQL. LIXA experimental PHP extension is based on mysqli and not mysql_nd. LIXA support for PHP must be considered experimental as stated here: http://sourceforge.net/p/lixa/wiki/FAQ%20Frequently%20Asked%20Questions/#how-can-i-use-lixa-and-php-together Happy to know at least one user is interested. LIXA support for PHP asks you to patch PHP code and build your own PHP run-time. You may use mysqlnd XA support or LIXA, but you would not be able to avoid the severe bug pointed by this note: http://sourceforge.net/p/lixa/wiki/FAQ%20Frequently%20Asked%20Questions/#mysql-special-notes pay attention to it because it can adversely affect your project at the worst time. Feel free to experiment both technologies. Hoping these hints will help you, please use the mailing list or the forum as your favorite discussion tools. Regards Ch.F. > Hi, which one is > better in terms of performance, when I would like to do a > transaction between two mysql database server, using this > one http://lixa.sourceforge.net/lixa-doc/ext/html/ch02s04.html#id3855642 > tx_begin(); > tx_commit(); > tx_rollback(); > or > http://php.net/manual/en/mysqlnd-ms.quickstart.xa_transactions.php > mysqlnd_ms_xa_begin(); > mysqlnd_ms_xa_commit(); > mysqlnd_ms_xa_rollback(); > please help me.. I dont want a java or .net which is very > expensive when I would like to ask for help, |
|
From: <lix...@li...> - 2014-05-02 20:54:30
|
Dear Mandar, please use this link to subscribe to this mailing list: https://lists.sourceforge.net/lists/listinfo/lixa-general but you can use discussion forum as well: https://sourceforge.net/p/lixa/discussion/934465/ Already answered to your question on discussion forum: https://sourceforge.net/p/lixa/discussion/934465/thread/1c1efc99/ I'm waiting for additional information. Regards Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions -------------------------------------------- Ven 2/5/14, lix...@li... <lix...@li...> ha scritto: Oggetto: [LIXA-general] LIXA tx_open error : -6 A: "lix...@li..." <lix...@li...> Cc: "Rahul Hegde" <Rah...@pe...>, "Yash Ganthe" <yas...@pe...>, "Abhishek Khadikar" <abh...@pe...> Data: Venerdì 2 maggio 2014, 16:23 Hi, We are building an application in C++ which interacts with DB2 server using XA transaction. For this we are using LIXA’s api and utilities to perform our task. However we are getting an error -6 i.e TX_ERROR which is related to Resource Manager is not available. We have client and the sever code of LIXA running on the same machine. However the DB2 server is on another AIX machine and we are connecting it from our code using ODBC driver. In spite of the DB2 server running on AIX we are getting RM not available error. My question regarding this are · Is it ok to have db server on another machine and lixa server on another machine. · Is it ok to have DB2 Server Hosted on AIX or it should be on linux only? · What could be the possible error for Resource Manager not available. Let us know in case if you need any more clarifications on this. PS1: attached are the logs that are generated by our code at LIXA_TRACE_MASK=0xffffffff. Thanks, Mandar. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -----Segue allegato----- ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs -----Segue allegato----- _______________________________________________ Lixa-general mailing list Lix...@li... https://lists.sourceforge.net/lists/listinfo/lixa-general |
|
From: <lix...@li...> - 2014-05-02 14:24:19
|
Hi, We are building an application in C++ which interacts with DB2 server using XA transaction. For this we are using LIXA's api and utilities to perform our task. However we are getting an error -6 i.e TX_ERROR which is related to Resource Manager is not available. We have client and the sever code of LIXA running on the same machine. However the DB2 server is on another AIX machine and we are connecting it from our code using ODBC driver. In spite of the DB2 server running on AIX we are getting RM not available error. My question regarding this are * Is it ok to have db server on another machine and lixa server on another machine. * Is it ok to have DB2 Server Hosted on AIX or it should be on linux only? * What could be the possible error for Resource Manager not available. Let us know in case if you need any more clarifications on this. PS1: attached are the logs that are generated by our code at LIXA_TRACE_MASK=0xffffffff. Thanks, Mandar. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. |
|
From: <lix...@li...> - 2012-05-25 20:07:55
|
Package lixa-0.9.2.tar.gz has been reloaded to SourceForge.net with this little patch: Index: download_and_patch.sh =================================================================== --- download_and_patch.sh (revisione 775) +++ download_and_patch.sh (copia locale) @@ -98,7 +98,7 @@ echo "File $ARCHIVE_NAME already available, bypassing download." echo "NOTE: if you want to download it again, please remove the current tarball ($ARCHIVE_NAME) and restart the script." else - wget -O $ARCHIVE_NAME http://docs.php.net/get/$ARCHIVE_NAME/from/docs.php.net/mirror + wget -O $ARCHIVE_NAME http://it2.php.net/get/$ARCHIVE_NAME/from/it.php.net/mirror if test $? -ne 0 then echo "Error while downloading PHP source code" http://docs.php.net/ disappeared in the meantime; there's no more a country unrelated mirror, so I choose an Italian one. Sorry for the inconvenience. Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions |
|
From: <lix...@li...> - 2012-05-24 20:12:59
|
Release 0.9.2 contains the new patch scheme for PHP previously available only via SVN. Regards Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions |
|
From: <lix...@li...> - 2012-05-11 19:53:36
|
> Da: "lix...@li..." <lix...@li...> > A: "lix...@li..." <lix...@li...> > Cc: > Inviato: Venerdì 11 Maggio 2012 21:49 > Oggetto: [LIXA-general] Patch for PHP 5.4.3 is available > >T he PHP team is releasing frequently due to some security fixes. > The LIXA project changed the technique used for PHP source code patching: > it's no more necessary a specific diff file for every distinct PHP release. > Now a single diff file can be applied to several distinct PHP source code > releases. > The new feature is available since Subversion revision 775; it will be released with 0.9.2 (work in progress). > Ch.F. > |
|
From: <lix...@li...> - 2012-05-11 19:49:24
|
The PHP team is releasing frequently due to some security fixes. The LIXA project changed the technique used for PHP source code patching: it's no more necessary a specific diff file for every distinct PHP release. Now a single diff file can be applied to several distinct PHP source code releases. Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions |
|
From: <lix...@li...> - 2012-05-03 20:18:52
|
PHP team discovered a security bug fixed with release 5.4.2: http://www.php.net/archive/2012.php#id2012-05-03-1 LIXA project supplies a patch for PHP 5.4.2 to avoid the security bugs. Subversion revision 773 address the issue; alternatively you can use LIXA 0.9.1 and patch PHP 5.4.2 manually: cd lixa/ext/php/php-5.4.2 patch -p1 < ../lixa-php-5.4.1-patch.diff Regards Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions |
|
From: <lix...@li...> - 2012-04-30 20:48:24
|
Dear all, release 0.9.1 is ready for download on SourceForge: https://sourceforge.net/projects/lixa/ This release add PostgreSQL to the list of Resource Managers that can be used with PHP language. It is now possible to develop PHP programs with distributed transaction processing between MySQL and PostgreSQL. Enjoy LIXA! Ch.F. ------------------------------------------------------------------- Decent workarounds outperform poor solutions |