asterisk

Commit Graph

Author	SHA1	Message	Date
Sean Bright	174006fcaa	docs: Indent <since> tags. Also updates the 'since' of applications/functions that existed before XML documentation was introduced (1.6.2.0).	9 months ago
George Joseph	54d67711f8	docs: Add version information to application and function XML elements * Do a git blame on the embedded XML application or function element. * From the commit hash, grab the summary line. * Do a git log --grep <summary> to find the cherry-pick commits in all branches that match. * Do a git patch-id to ensure the commits are all related and didn't get a false match on the summary. * Do a git tag --contains <commit> to find the tags that contain each commit. * Weed out all tags not ..0. * Sort and discard any .0.0 and following tags where the commit appeared in an earlier branch. * The result is a single tag for each branch where the application or function was defined. The applications and functions defined in the following files were done by hand because the XML was extracted from the C source file relatively recently. * channels/pjsip/dialplan_functions_doc.xml * main/logger_doc.xml * main/manager_doc.xml * res/res_geolocation/geoloc_doc.xml * res/res_stir_shaken/stir_shaken_doc.xml	9 months ago
Jaco Kroon	6d2614be68	res_odbc_transaction: correctly initialise forcecommit value from DSN. Also improve the in-process documentation to clarify that the value is initialised from the DSN and not default false, but that the DSN's value is default false if unset. ASTERISK-29311 #close Change-Id: I46e2379f7b0656034442bce77cb37ccd4e61098d Signed-off-by: Jaco Kroon <jaco@uls.co.za>	5 years ago
David M. Lee	eb0c9c476f	res_odbc_transaction: add dep on generic_odbc When res_odbc_transaction depended on res_odbc, it got the generic_odbc headers and libs implicitly. Now that it no longer depends on res_odbc, its dependency on generic_odbc must be explicit. Change-Id: I9db88f7af7388437f49903d3008ba8d4890d5911	9 years ago
George Joseph	c7ffd6111d	res_odbc: Correct the dependency relationship with res_odbc_transaction The MODULEINFO dependencies between these 2 modules was reversed. res_odbc should depend on res_odbc_transaction, not the other way around. ASTERISK-25984 #close Change-Id: Ifcfbb49c0b51cf6640a5446d47cd6c48caf1331f	9 years ago
Rodrigo Ramírez Norambuena	f690c105f3	res_odbc_transaction: fix some format tab Change-Id: I265e4ac47c629c9a63dd86b59df82a7ab3c64384	10 years ago
Mark Michelson	9714da7aa4	res_odbc: Remove connection management Asterisk by default will create a single database connection and share it among all threads that attempt to access the database. In previous versions of Asterisk, this was tolerable, because the most used channel driver, chan_sip, mostly accessed the database from a single thread. With PJSIP, however, many threads may be attempting to perform database operations, and there is the potential for many more database accesses, meaning the concurrency is a horrible bottleneck if only one connection is shared. Asterisk has a connection pooling facility built into it, but the implementation has flaws. For one, there is a strict limit on the number of simultaneous connections that could be made to the database. Anything beyond the maximum would result in a failed operation. Attempting to predict what the maximum should be is nearly impossible even for someone intimately familiar with Asterisk's threading model. In addition, use of transactions in the dialplan can cause some severe bugs if connection pooling is enabled. This commit seeks to fix the concurrency problem by removing all connection management code from Asterisk and leaving that to the underlying unixODBC code instead. Now, Asterisk does not share a single connection, nor does it try to maintain a connection pool. Instead, all Asterisk ever does is request a connection from unixODBC and allow unixODBC to either allocate those connections or retrieve them from a pool. Doing this has a bit of a ripple effect. For one, since connections are not long-lived objects, several of the safeguards that previously existed have been removed. We don't have to worry about trying to use a connection that has gone stale. In every case, when we request a connection, it has just been made and we don't need to perform any sanity checks to be sure it's still active. Another major player affected by this change is transactions. Transactions and their respective connections were so tightly coupled that it was almost pornographic. This code change moves transaction-related code to its own file separate from the core ODBC functionality. This way, the core of ODBC does not even have to know that transactions exist. In making this large change, I had to look at a lot of code and understand it. When making this change, I discovered several places where the behavior is definitely not ideal, but it seemed outside the scope of this change to be fixing it. Instead, any place where I saw some sort of room for improvement has had a XXX comment added explaining what could be altered to improve it. Change-Id: I37a84def5ea4ddf93868ce8105f39de078297fbf	10 years ago

7 Commits (08a588e200e179593edd174f7bb7a831970fc978)